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(57) Abstract: System and method for enabling application server request failover. For each application server request to be per- 
fonned by a client computer, a requesting thread may be operable to utilize a custom wiie-level communication protocol. Request 
faOure detection mechanisms may built into the custom wire-level conmiunication protocol so that a requesting thread detects a 
failed request much sooner than if the thread utilized a standard communication protocol and relied on the cUem computer opesatiog 
system for notification of failed requests. After sending a request to an applicau'oo server, a requestiiig thread may be opoable to 
"sleep* and then periodically wake up to poll the application server computer to determine whether the request has failed: If the re- 
questing thread receives a response' from the application server computer indicating that the request is not currently beiog processed, 
then the requesting thread may re-send the request. Receiving no response to the poU message may indicate that the application server 
computer is ofiline, e.g., due to a failure. The requesting thread may redirect the request to anotlier ai^lication server computer if 
neoessaiy. 
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TITLE: SYSTEM AND METHOD FOR ENABLING APPLICATION SERVER REQUEST FAILOVER 

BACKGROUND OF THE INVENTIOW 

5 

1. Field of the Invention 

The present iDvention relates to the field of application scrveis, and more particularly to a system and 
method for enabling application server request failovcr. 

10 2. Description of the Related Art 

The field of application servers has recently become one of the fastest-growing and most important fields 
in the confuting industiy. As web applications and other distributed applications have evolved into large-scale 
applications that demand more sophisticated confuting services, specialized application scrms have 
necessary, in order to provide a platform supporting these large-scale applications. Applications that run 

15 application servers are generally constmcted according to an n-tier airchitecturc, in which presentation, 

logic, and data access layers are kept separate. The application sender space is sometmaes referred to as. 
•^ddlcwarc**, since application servers are often responsible for deploying and running tibe business logic layer 
and for interacting widi and integrating various enterprise-wide resources, such as web servers^ da t a b ases, and 
legacy systems. 

20 Application servers offci significant advantages over previous appaadm to inq>lementing ^«b. 

applications, such as usiiig connnon gateway interface (CGI) scrqpts or prt^grams. Figaic I tlhistFates a typical 
architecture for a web applicadpn utilizing CGI scr^ts or programs. The client computer running a web browss 
may reference a CGI program on the web server, e.g., by referencing a URL such as 'iitQ)://server.domainxoin/!^i- 
bin/myprogram.pr. Gcncially, the CGI program runs on the web server itself, possibly accessing a database, e^ 

25 in order to dynamically generate HTML content, and the web server returns the output <^1he program to the web 
browser. One drawback to this approach is that the web server may start a new process each time a CGI ptogram or 
script is invoked, which can result in a high processing overhead, impose a limit on die mrnib fr r of GGl piugiauis 
that can run at a given time, and slow down the performance of the web server. In c witi a st , applkatian seivca 
typically provide a means for enabling programs or program con^onents that are referenced via a URL to run m m 

30 separate con^uter from the web server and to persist between client invocations. 

Another common drawback of previous web application design models, such as the use of C?G1 programs, 
is related to data access. For example, if a CGI program needs to access a database, the program typically opens m 
database coimection and then closes the connection once it is done. Since opening and closing d atnhasr 
coimections are expensive operations, these operations may further decrease the performance of die wrf> saver 

35 each riwtg a CGI program runs. In contrast, application servers typically provide a means to pool database 
coimections, thus eliminating or reducing the need to constantly open/close database coimections. Also, data access 
in CGI programs is generally coded at a relatively low level, e.g., using a specific dialect of SQL to access a 
specific type of database. Thus, pordons of the application may need to be recodcd if the database is replaced with 
a new type of database. Application servers, on the other hand, may provide a database service for app&atioiB to 
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utnize as » interface between the application and the database, which can serve to ab«ract the appHcatioa from a 

particular type of database. - • j «• 

AppUcadon scxvexs nuy also provide many other types of appUcation services or my provide stand»d 
reusable consents for tasks that web applications connnonly need to perform. AppUctioa often 
i„con>otate these services and components into ». integrated development enviromnem speciabzed for cre«-g 
web appUcations. ^ integmted development environmem may leverage various standard software component 
n^dels. such as the Common Object Request Broker Architecture (CORBA). the pism-butcd) Component Object 
Model (COMA)COM). Enterprise JavaBcans~ (EJB). etc, or the integrated development enviromnent may 
provide its own software component model or may extend standard component models in vahous way.. 

Tte following list is a partial list of *e types of appUcation services or application cmnponents that 

appHcadon servers may provide. By leveraging these types of integrated, prcbuflt s«vic« «d «--J-"«;-* 

a^licadon developers may realizeasigniftcantreductio»inappli«^ 

dLop a mom robust, bug-ftee appUcation. Application servers ftom different vendors differ, of course. - 
0^ of services they provide; thus, ihe fonowiag list is exemplaiy only. 

. AS «.ted above, application serv«s may provide data access services for accessing v»io-s types of da«b^ 
eg. through directly supporting proprietary databases, such as S^^ 

^dized interfaces, such as ODBC. JDBC. etc. Also, as noted above. -wlic«ion servers m-y e«Ue 
^aia*"**^ rtmnection pooKng or cachin g. 

i™. ^mnde services for accessing network directories, sudi a» directories Aat 
• Application servers may also provide services lor 

support the standard lightweight Directoiy Access Proiocd (LDAP). 

. AppHcation servers may also provide application security services or component. W* ipplicafian seo^ 
be considered at difTercn, levels, such as: dicnt-to-server communicatio-. applicaticKlevel prrvilega. 
daubase access, directory sendee «xess. etc Application server security-related servicesfcomponent. may 
include support for perfonning user authentication, performing data encryption, commmucating vui s«^ 
pnHocols such as Secure Sockets Layer (SSL), utilizing security certificates, progmmming user aeces. ngh-. 
integrating wi* operating system security, etc 

AppUcation serven, may also provide services enabUng a web application to easily 
information during a user session or across user sessions. Perfonning state «>d - 
especially important for appUcations that have complex, multi-step transactions. 

Application servers may also support caching the results of application logic execution or cach^tbe results of 
webpage/componentoutput.sothatforappropriates»bsequentrequests.tfae.esultsmaybere^ 
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Application seivos may also support resuh streaming, such as dynamically streaning HTIP output, which 
may be especially usefiil for large resuh seu involving lengthy queries. A related service may diable ao 
application to easily display a large result set by breaking the resuh srt down into smaller groups and 
di^laying these groups to the user one at a timB. 

. Many web applicatiims need to perform various types of searching or indexing operations. Application seivert 
may also provide application services for indexing or searching various types of documenis. databases, etc 

• As nottd above, many web applicatjwis may perform various types conidex. muUi-stq) transactions. 
Application servers may also provide support for managing d»ese appUcation transactions. For example, this 
suppan may be provided via a software conqwnent model supponed by the application server, such as the 
Enterprise JavaBeans"' conqwnent model, or via integration with tiurd-party transaction process monitors, etc 

• It is often desirable to enable wtb applications to perform certain operations indqiendoatly. as opposed to in 
response to a user requ«L For example, it may be desirable for an application to automatically send a 
newsletter to users via emafl at regularly scheduled intervals. Application savers may support the cieatian and 
scheduling of events to perform various qrpes of operations. 

• Many types of web applications need to perfrnm e-commerce transactions, such as credit card transactions, 
financial data exchange, etc, Application servers may provide services for performing various types of e- 
coinmerce transactions or may provide an integrated tinrd-party e-commeice package for ^to^ 

• Web aRilications often need to utilize various types of Standard network application services, such as an emaa 
service. FTP service, etc Application servers may provide diese types of seiviees and may enable appUcatitnis 
to easily integrate wifli die services. 

• Web applications often need to log various conditions or events. AppUcation servers may provide aD 
integrated logging service for web applications to use 

Judging by die ex^lary list above of confuting services fliat application servers may provide for w* 
appUcations. it is apparent tiiat application servers may integrate a diverse range of services, where these senrices 
may interact with many different types of servers, systems, or other services. For example, an application server 
may act as a ptotfonn hnb connecting web servers, database servers/services, e-commerce servers/services, legacy 
systems, or any of various other types of systems or services. A key benefit of many application servers is that drey 
not only provide tfus service/system integration, but typicaUy also provide centralized administrative or 
management tools for performing various aspects of system and application administration. 

For example application servers may provide management tools related to application development and 
dcploymem. such as toob for source code control and versioning, bug tracking, workgroup development, etc 
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Application scrvcis may also provide tools related to application testing and deployment, such as tools for 
application prototyping, load simulation, dynamic code base updates, etc. Application servers may also provide 
tools for easfly configuring the application to utilize various of the appHcation server services described above. For 
exair^le. administrators may use a tool to set the result caching criteria for particular application con^onents or 
pages, or may use a tool to specify which documents to index or to spcciiy indexing methods, etc 

One important class of application server administrative tools pertains to real-tiine applicatifm 
management and monitoring. Application servers may provide tools for dynamically managing various lacton 
affecting application performance, e^. adjusting the application services and support features described above. 
For example, application server tools may allow adnunistrators to: 

• dynamically adjust the number of database connections maintained in a database pool, in order to determine 
the optimum pool size for maxinnim perfo 



• clear or resize application output ca che s 

• dynamically change various aspects of system or application security 

• schedule or trigger events, such as events for sendmg e-mafl reports to applkation users, generating rqpoits 
based on collected data, etc 

• start and stop various appKcation services, such as email or FTP services, from a centralized user interftce 

Thfa list is. of course. exciiq)lary, and particular application servers may support difiTacnt types of centra&ed 
application managemenL 



hi addition to the factors discussed above, many appHcation servers also inchide means for providmg 
various types of system reliability and fault tolerance. One common technique related to fauh tolerance is known 
as application server "chistcring^ Apphcation server clustering refers to tying toge&er two or more application 
servers into a system. In some cases, this -tying together^ may mean that application code, such as particular 
software components, is replicated on multiple application servers in a cluster, so Aat in the case of a hardware ot 
software failure on one application server, user requests may be routed to and processed by other appHcation 
servers in the' cluster. 

Application server clustering may also faciUtate application performance and scalability. Application 
servers may be added to a chxstcr in order to scale up the available processing power by distributing work. 
35 Advantageously, application servers often enable this type of scaling up to be down without requiring changes to 
die application code itself. 

Work may be distributed across an apphcation server chister in different ways. For example, as^discussed 
above, application code may be replicated across mult^le application servers in the chister, enabUng a given 
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request to be processed by asy of these multiple application servers. Also, applicatioD code may be logically 
panitioxicd over multiple servers, e.g., so that a particular application server is responsible for perfonning particular 
types of operations. This type of application partitioning may help application performance in various ways. For 
example, application partitioning may reduce the need for an application server to perfonn context switching 
5 between different types of operations, such as CPU^inlensiye operations versus input/output-intensive operations. 
Also, application partitioning may be used to match application processing to various physical characteristics of a 
system, such as network characteristics. For example, data-intensive application logic may be configured to lun on 
an application server that is closest to a data source, in order to reduce the latencies associated with accessing 
remotely located data. 

10 In the case of application code replication, where multiple application servers arc capable of processiog a 

given request, it is often desirable to route the. request to the •i>est" application server currently available to process 
the request, i.e., to the application server that will enable the request to be processed and tibe request results to be 
returned to the client as quickly as possible. This mapping of client requests to application servers is known as 
application server load balandng. 

15 Given the types of critical applications that may run on application serveis, application failure recovcfy • 

mechanisms axe as especially important area 'for application serveis to address. One possible point of failure in a 
system is between a client computer, such as a web server, and the application server. The term '*req[aest faflover^, 
as ttscd herein, refers to methods applied to prevent, detect, and/or recover from failures that occur once a client 
computer performs a request and begins to wait on the request results. Existing application server request failover 

20 approaches often suffer from various disadvantages. For exaxx^le, the client computer may rely on the operating 
system to inform the client computer of broken cormecticms, which may result in a nmcb longer dian necessaiy time 
interval for the broken connection to be discovered. 

SUMMARY OF THE INVENTION 
25 The problems outlined above may in large part be solved by a system and method for enabling application 

■ server request failover, as described herein. The application server may support networiced applications, sach as 
web applications or other Internet-based applications. The applications may run on a system including one or more 
client computers, e.g., web senders, that perform requests referencing application con^ments running oo an 
application server. The system may also be configured to utilize a cluster of application servers in which requests 
30 from the client coii7Uter(s) are distributed across different application servers. 

For each application server request to be performed by a client computer, a particular thread running on 
the client corriputcr may perform the request The requesting threads may be operable to utilize a custom wirc4evcl 
communication protocol, as described below, for communicating with an application server computer. Request 
failure detection mechanisms may be built into the custom wire-level communication protocol so that a requesting 
35 thread detects a failed request, e.g., due to a lost coimection between the client computer and the application server 
computer, an application server conqniter failure, etc., much sooner than if the thread utilized a standard 
communication protocol and relied on the client computer operating system for notification of failed requests. 

After sending a request to an application server, a requesting thread may be operable to -slcq)", using 
standard operating system techniques. The requesting thread may then periodically wake up to poll the application 
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server coniputer to determine whether the request has faflcd. In one cmbodiinent, this poIUng is perfonned by the 
requestmg thread sending a User Datagram Protocol (UDP) message comprising infoimation identifying the tequcst 
to the application server. Upon receiving the UDP message, the application server is operable to use the request 
information to determine the stanis of the identified request and inform the requesting thread of the request status. 

If the requesting thread receives a response from the application server con^uter indicating that 4c 
request is not cuircnUy being processed, then the requesting thread may rc-scnd the request Receiving no reqx>nsc 
to the poB message may indicate that the application server computer is offline, e.g., due to a failure, in one 
embodiment, the application server computer may be one node in an application server chistcr, as described above. 
In this case, the requesting thread may redirect the request to another application server counter. The requesting 
thread may update information maintained on the cKcnt conqniter regarding the status of each api^ication server 
con^mtcr, to indicate that the appUcation server con^utcr to which the request was sent is currently offline. Fumie 
requests will then be sent to other conqmters in the application server cluster. The cKoit conqmtcr may attcnqrt to 
poU the offline application server computer periodically, in order to determine when tht: offline appHcation server 
becomes available again. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Odier objects and advantages of the invention will become apparent upon xeadii^ die foHowing detailed 
description and upon reference to the acconqnnying drawings in whidu 

20 F{guxel iflustrates a typical architecture for a web application utflizingCXjI scripts or p 

Figures 2A - 2C iUustrate exemplaiy architecmres for networiced applications nmaing on application 

serven; 

25 Figure 3 is a block diagram illustrating one embodiment of an application server and processes tfiat nm on 

die explication server; 

Figure 4 illustrates several system-level services that may be involved in managing application server 

requests; 

30 

Figures 5 and 6 ilhistrate various embodiments of a web server client with a web server phig-in comprismg 
a load balancer component that distributes requests across an application server cluster 

Figure 7 ilhistratcs a duster of application servers in which each application server comprises a load 
35 balancing service; 

Figure 8 illustrates a table of excn^lary server load criteria that may be used in deciding whitA application 
server is best able to process a current request; 



6 



BNSOCDDc <WO ^01 13SZ7A3LI_> 



10 



wo 01/13227 PCTAJS00/22CeS 

Figure 9 illustrates a table of excmplaiy application component peifonnance criteria that may be used tn 
deciding which application server is best able to process a current request;. 

Figure 10 illustrates an exemplary user interface screen for setting server load criteria values; 

Figure 1 1 illustrates a user interface partial tree view of application servers in an application server cluster; 

Figure 12 illustrates an exenq)lary user interface screen for setting application component performance 
criteria values; 

Figure 13 iDustrates an exemplary user interface screen for setting broadcast and update intervals for 
sharing load balancing information among application servers in an application server chistei; 

Figure 14 illustrates an exemplaiy user interface of a tool for enabling adminisliatuis to specify '^lick/* 
15 load balancing for certain application conqponents; 

Figure 15 is a flowchart diagram illiistrating one embodiment of a method for enabling application saver 
recpiest iailovei; 

20 Figure 16 is a flowchart diagram illtistrating one embodiment of a method for dynamically discoveiiag 

and reloading classes; 

Figure 17 is a flowchart diagram illustrating one embodiment of a method for determining whedier a class 
should be dynamically reloaded when modified; 

25 

Figure 18 is a flowchart diagram illustrating one embodiment of a method fox performing atomie dass* 

loading; 

Figure 19 is a flowchart diagrani illustrating one embodiment of a method for enabling JSP response 

30 caching; 

Figure 20 illustrates an exesrqplary user interface of a tool for managing message logging; 
Figure 21 illusirates an exemplaiy type of database table for logging messages; 

35 

Figure 22 illustrates an exenxplary type of database table for logging HTTP requests; and 

Figtire 23 is a flowchan diagram illustrating one embodiment of a method for handling out-of-storage- 
space conditions when logging messages. 
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Whfle the invcntioB is susceptible to various modificatioDS and alternative foxins, specific embodiments 
are shown by way of exan^le in the drawings and arc herein described in detaiL It should be understood however, 
that drawings and detailed description thereto are not intended to limit the invention to the particular form 
disclosed, but on the contrary the invention is to cover all modifications, equivalents and alternatives falling within 
5 the spirit and scope of the present invention as defined by the appended claims. 

DETAILED DESCRIFTION OF THE PREFERRED EMBODIMENTS 

Figure 2 - Exemplary Application Architectures 

10 Figures 2A - 2C illustrate exemplaiy architectures for networked applications running on application 

servers. There are, of course, many possible archiuctural variatiox&s, and Figures 2A - 2C are exen^lary only. 

Figure 2A illustrates an exenq>lary architecture for a web application. In general, a web application may 
be defined as an Internet or Intranet-based application comprising a collection of resources that are accessible 
through uniform resource locators (URLs). The resources may include web pages con^irising HTML. XML, 

15 scripting code such as Javascript or VBScript, or o&er types of elements. The resources m^ also inchide aiqr of 
various types of executable programs or con^onents, such as CGI programs, Java servtets, JavaBeans componeoss. 
CORBA conqmnents, downloadable code sudi as Java classes or ActiveX coizxponenis, etc The resomces may 
also include any other type of resource addressable through a URL. 

The embodiment of Figure 2A illustrates a client con^utcr 100 running a w^ browser, such as die 

20 Netscape Navigator or Microsoft Internet Explorer web browsers* It is noted that die web-browser need not be a 
web browser per sc, but may be any of various types of client-side applications Aat inchide web-browsing 
functionality. For exan^le, Microsoft Corp. provides progranmiing inter&ces enabling applications to incoxporate 
various web-browsing capabiUties provided by the MicrosofI Internet Explorer code base. 

The web browser rnay run in any type of client coxnputcr 1 00. For cxan^le, the web browser may run 

25 desktop computer or workstation running any of various operating systems, such as Windows, Mac OS, Unix, etc, 
or the web browser may run in a portable computing device, such as a personal data assistant, smart cellular phone, 
etc. The client computer 100 may use a network coimection for commtmicating witfi a wd» seiver 104 via a 
network 102, such as the Internet or an Intranet The client network connection may be a connection of any type, 
such as a PPP or SLIP dialup link, an Ethernet or token ring connecticm, an ISDN coimection, a cable modem 

30 connection, any of various types of wireless connections, etc. Although web applications are often associated with 
particular communication protocols, such as HTTP or SSL, it is noted that any communication protocol, inchiding 
TC3*-based protocols and UDP-based protocols, may be used to communicate over the network 102* 

As the web server 104 receives a request from a client computer 100, the web server may treat tfie request 
differently, depending on the type of resource the request references. For exanqile, if Ae request references a 

35 document 106, such as an HTML document, then the web server may process the request itseU; eg., by retrieving 
the document from the web server's local file system or from a local cache and remming the document to the dicnt 
comtputer. For other types of requests, e.g. requests referencing executable components, such as Java servlets, 
JavaBeans con^jonents, C program modules, CORBA components, etc, the web server may broker the request to 
an application server 108. As described in more detail below, the web server 104 may interface with an application 
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server through an in*process extension, such as an ISAPI ox NSAP] extension. It is noted that h is possible to 
incorporate the functionality provided by the web server into an integrated application server. 

The application server 108 may be configured as a pan of an application server cluster, as described above 
and shown in Figure 2A. Although Figure 2A illustrates an application server cluster with only two application 
5 servers, it is noted that the cluster may comprise any number of application servers. Each application server may 
interface with various types of other servers or systems. For example, as illustrated in Figure 2A» the applicatioD 
servers may connnunicate with a database 110. Each application server in the cluster may mtexface with the sane 
systems, or the application servers may differ in which systems they interface with. For example. Figure 2B is 
similar to Figure 2A, but in the embodiment of Figure 2B, apptication server 108B is shown to interface with a 
10 legacy system 1 12. Application servers in a cluster may not need to be in close physical proximity to each otiier. 

It is noted that, in altematiye embodiments, a client computer may communicate directly with an 
application server or application server cluster, without interfacing through a web server* Figuic 2C illustrBtcs a 
client computer 1 14 communicating directly with application servers 108. For exan^le, die applieation servets 
may run an enterprise resource plaiming application, and the client computer 1 14 may be a computer widiin the 
15 enterprise that is connected to the application servers via a WAN. In this example, the client ccm^ter may nm 
**thick client" software, e.g., chent software chat conqmses a portion of the enterprise resource plaxming appHcation 
' logic The client computer software may interface directly with executable programs or coiiqKments running on die 
application servers, e.g. through a protocol such as the Internet Inter-Orb Protocol (IlOP). 

As noted above. Figures 2A - 2C are exenq>]aiy architectures only, and many variations are possSblt* As a 
20 small handful of exanq}les of ahemative embodiments, multiple web servers may be present to receive requests 
from client con^uters and broker the requests to plication servers, the web server may itself tnteiiace directly 
widi a database, application servers may interface with various other, types of systems, sucli as specialized 
authentication servers, e-commcrce servers, etc 

25 Figure 3 - Service and Component Management 

Applications that run on application servers are often constructed from various types of software 
con^nents or modules. These components may include conqsonents constructed accordii^ to a standard 
con^nent modeL For example^ an application may comprise various types of standard Java^ components such as 
Enterprise JavaBcans^ con^onents, JavaScrvcr Pages''**, Java Scrvlets''**, etc. An application may also con^rise 

30 any of various other types of components, such as Conmion Object Request Broker Architecture (CORBA) 
components, Conunon Object Model (CXDM) components, or components constructed according to various 
proprietary component models. 

Each request that an application server receives ftom a client may reference a particular application 
component Upon receiving a request, the application server niay determine the appropriate con^xmem, invoke die 

35. conq>onent, and renim the execution results to the client In various embodiments, it may be necessary or desirable 
for different types of application server components to run within different environments. For example, an 
appbcation server may support both components wrinen using the Java^ programming language and conq>bncnts 
wrinen using the C or C-m- programming languages. In such a case, the different types of con^nents may be 
managed by particular processes or engines. 
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For example. Figure 3 illustrates an application seivcr 200 in which a process refeircd to as the "executive 
server^ 202 runs. As shown, the executive server 202 interfaces with a process 204. referred to as a "Java servo^ 
and a process 206 referred to as a •*aC++ server". In this embodiment, the executive server 202 may receive client 
requests, assign the client requests to a particular thread, and forward the requests to either the Java server 204 or 
5 the C/C++ server 206, depending on whether the requests reference a component that executes within a Java 
runtime environment or a C/C++ nmtime environment. The Java server or aC++ server may then load and 
execute the appropriate component or module. 

In addition to interfacing with the Java and aC++ servers, the executive server 202 may also manage 
various system-level seivices. For example, as discussed below, the executive server may manage a load balancing 
10 service for distributing requests to other application server computers in a chister, a request manager service for 
handling incoming requests, a protocol manager service for communicating with clients using various proUKols, an 
event logging service for recording conditions or events, etc 

In addition to managing application components, the Java server 204 and the OC++ server 206 may also 
host and manage various application-level services used by the application components. These appUcation-level 
15 seivices may include services for managing access to databases and pooling database connectiona. services for 
performing state and session management, services for caching ou^ut results of particular application conq)Otteiits, 
or any of various other services such as described above. 

Figure 3 aUo ilhistratcs a process 208 referred to as the -administrative server^ . As described above, an 
application server environment may provide an adminisnrative tool for adjusting various factois affecting 
20 application execution and performance. In the embodiment of Figure 3. such an administrative tool may interface 
with the administrative server 208 to adjust these factors. For cxan^lc. administrative tool 208 may be enabled 
to adjust the evcm logging criteria used by die executive server's event-logging service, adjust die number of 
database connections pooled by the Java or C/C++ server's data access service, etc The administrative server 208 
may also provide faihirc recovery by monitoring the executive server. Java server, and C/C++ server processes and 
25 restarting these processes in case of failure. 

Figure 3 of course represents an exemplary architecture for managing application con^onents. system- 
level services, and appUcation-level services, and various other embodiments are contemplated.: For exanqile, 
although Figure 3 is discussed in tenns of Java™ and ac++ components, various other processes or engines may 
be present for executing other types of software components or modules. Also, various embodiments may support 
30 multiple component management processed c.g. multiple Java server processes or aC-H+ server processes. TTie 
number of processes may be adjusted via an administrative tool interfacing with the administrative server. 

Figure 4 - Application Server Systent-Lcvel Services 

Figure 4 iDustrates several system-level services which may be invoWed in managing application server 
35 requests. In one embodiment, these systcm-level seivices may be managed by an executive server process such as 
described above with reference to the Figure 3 application server. 

Figure 4 ilhistratcs a protocol manager service 220. The protocol manager service 220 is responsible for 
managing network communication between the application server 230 and clients of the appUcation server. For 
exanqjle. Figure 4 illustrates a web saver client 240 which comprises a staiidard web server extension or phig-in 
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242. The web stiver plug-in 242 may be any of various well-known types of plug-ins enabling web servers to 
conununicaie with other systems, including NSAPI, ISAPI, optimized CGI, etc. As shown, the protocol manager 
service 220 includes "listener^ modules or con^onents, e.g. an NSAPI listener, ISAPI listener, etc, for 
communicating with the web server plug-in. The listener modules may communicate with the web server phig-in 
5 via the standard HTTP or HTTPS protocok. 

Figure 4 also flhistrates that other types of clients besides web servers may commtmicate widi the 
apphcation server 230. For exanqsle, a client computer 250 is shown. The client computer 250 may run an 
application program, such as a program wrinen in Java^ or C-^, that conununicates with the application server 
230 using any of various commtmication protocols. For example^ as shoira in Figure 4, the protocol manager 

10 service 220 may support such protocols as llOP, RMI, DCOM, OCL Service, or any of various other protocols. As 
an example, an administration program for configuring an application server may comnnmicate dirisctly widi the 
application server 230 through such a protocol, rather than routing requests through a web server. 

As shown in Figure 4, an application server may also include a load balancing service 222. In the case of 
application server clustering, requests may first be processed by the load balancing scivice in order to determine 

15 whether die request should be processed by the current application server or would be better seived by forwarding 
the request to another application server in the cluster. Load balancing is discussed in detafl below. 

As shown in Figure 4, an application server may also include a request manager service 224. Once die 
load balancing service detcmiincs that the current application server should process the client request <if load 
balancing is applicable), the request manager service is responsible for managing, the proce^ing of the req[oe8L As 

20 shown in Figure 4, the request manager service 224 may include several coinponents or inodules» siicli as a request 
manager, a dnead manager, and a queue manager. In cme embodimait, client requests may be processed in a mnhi- 
thieaded fashioiL The thread managermodule may manage a pool of direads avaflable for processing requests. In 
one embodiment, the nuniber of threads in the pool may be adjusted using an administrative tooL 

When the request manager module receives a client request, the request manger module may call die 

25 thread manager module to anempt to assign the client request to a thread. If no threads are currently available, then 
the request manager module may call the queue manager module to queue the request until a thread beconiBS 
available. The queue manager module may maintain information regarding each client request, such as die request 
ID, the processing status, etc. 

30 Application Server Load Balancing 

As discussed above, it is often desirable to configure a cluster of application servers so that cHent requests 
may be distributed across the cluster, i.e., to perform application server load balancing. Given the diverse nature of 
applications that may be deployed on application servers, it may be desirable to provide a system i»*ose load 
balancing criteria are highly configurable using many different factors in order to achieve qptimal application 

35 performance. This section discusses several load balancing methods. In various embodiments, application serven 
may support any of these load balancing methods of any combination of the load balancing methods described. 
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Load Balancing Detennmed by Web Server Plug-In 

One general approach which may be used in selecting an application server to send a request to is to leave 
the decision to the client The cUent may keep track of the response times seen over time from various appUcation 
servers and may choose to send requests to the application server with the historically fastest response times. In 

5 many cases, the "client" of an application server is a web server. As shown in Figure 4. a web server may have a 
web server phig-in which includes a load balancer component or module. This load balancer componem may be 
responsible for monitoring which application servers are available in a cluster to service requests, may record the 
response times seen for requests serviced by each application server, and may use this information to determine die 
most appropriate application server to send a given request to. 

10 The load balancer component of the web server phig-in may be configured, using an administrative tool, to 

use different levels of granularity in making the response time decisions. As discussed above, client requests 
gencrany reference a particular executable component on an application server. For example, a URL sudi as 
*1itip://server.domain.com/abc.jsp** may reference a JavaServer Page^ component, -abc.jsp-. In an exemplary 
system in wWch the •^bc.jsp- corrqwmcnt is replicated across three application servers. Application Server A.. 

15 Application Server B, and Application Server C, the average response time, as seen from the time the request 
referencing the -abc.jsp" component is sent to the appKcation server to the time the request results are received 
. from the application server, may be as follows: 

Application Server A: 0.7 sec 

20 Application Server B: 0.5 sec 

Application Server C: 13 sec 

In such a case, it may be advantageous to enable the load balancer con^oncnt of the web server to send a request 
referencing the •*abc.j^" conqwncnt to Application Server B. In other words, load balancing may be performed an 

25 a "per-conq>oncnr basis, where each request referencing a particular component is sent to the appUcation server 
which has historically responded to requests for that con^nent die fastest 

Performing load balancing on a per-^orrqwnent basis may benefit application performance for certain 
types of applications. However, for other applications, tracking such response-time information on a per. 
component basis may result in overhead that outweighs the benefits. Thus, the load balancer component of die wd> 

30 server may also make decisions on a "per-server" basis. That is, die dcterminarion of which application saver to 
send requests to is based on die average response time for all requests. It is noted Aat in one embodiment the per- 
server and per^omponcnt mcdiods may be combined, so diat adminisnrators may specify a particular set of 
components for which die load-balancing decisions are made based on a pcr-component basis, whfle decisions are 
made on a per-scrver basis for default components. 

35 Figure 5 illustrates one embodiment of a web server client 300 wiUi a web server plug-in 302 conqmsing a 

load balancer conqjonent 304 which distribmes requests across an application server chister (appUcation servers 
308A - 308C). As shown, die load balancer component 304 may maintain a table or Ust of response times BOd, to 
be used in making load balancing decisions as described above. 
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The client, e.g.» the load balancing component of the web server plug-in^ may also make load balancing 
decisions based on factors other than response times. For example, in one embodiment, administrators may assign 
a *Veight*' to each application seivex in a cluster, using an administrative tool A weight may be assigned to each ' 
application server based on the server's resources, such as the number of CPUs, the memory capacity, ete. The 
5 application server weights may then be used in various request distribution algorithms, such that requests are 
distributed among the. application servers in proportion to their weights. For example, weights may be used in a 
weighted round-robin algorithm or may be applied to enforce even distribution for certain types of requests, as 
described belofw. 

Figure 6 illustrates one embodiment of a web server cliem 300 with a web server plug-in 302 conq^rising a 
10 load balancer con^nent 304 which distributes requests across an application server cluster (application servcn 
308A - 308C). As shown, a weight is assigned to each application server in the cluster, and the weights are used m 
a weighted load balancing algorithm. 

Load Balancing Determined by Application Server Load Balancing Service 

15 Instead of leaving load balancing decisions to the client, based' on such factoss as response times and 

server weights, in various embodiments the applicaticm servers themselves may be responsible for distributing 
requests among different computers in the application server cliister. For example, in the Figure 4 example, die 
application server 230 con^rises a load balancing service 222 that f>erfoTms request loaid balancing. Figure 7 
Ohistrates a cluster of application servers 320A - 320D in which each application server ccmiprises a load balanciog 

20 service330. 

The load balancing services of die application servers may share infosmation to be used in deciding wbaA 
application server is best able to process a current requesL One class of infonnation ibat may be ^ctored into diis 
decision is referred to as **server load criteria.** Server load criteria includes various types of information that may 
be indicative of how ^usy** an application server currently is, such as the CPU load, the input/output rate, etc 
25 Figure 8 illustrates a table of exemplary server load criteria. Any of various other factors affecting server 
performance may be considered in. odier enibodiments. 

Arwther class of information that, may be factored into load balancizig decisions is refened to. as 
**application con^nent performance criteria**. Application coniponent performance criteria includes infomiatioa 
regarding the performance of a particular application component, e.g. a particular JavaServcr Pages^ component 
30 Figure 9 illustrates a table of exemplary criteria that may affect application component performance. For exarrq>le. 
Figure 9 illustrates a **Cached Results Available** critdion. As discussed below, in various embodiments, the 
execution results of application components, such as JavaServer Pages^ components, may be cached. Reusing 
execution results cached on a particular application server may resuh in faster processing of a requesL 

Another exemplary criterion listed in Figure 9 is "^osi Recently Executed**. For some types of 
35 application components, distributing a request to the application server .that most recently ran the application 
contponent referenced by the request may resuh in faster processii^ since that application server may still have 
context information for the application component cached. 

Another exemplary criterion listed in Figure 9 is ^Fewest Executions**. In some cases, it may be desirable 
to distribute different types of requests evenly across all application servers in a duster. Thus, the application 
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server that has run.the application component referenced by a request the fewest number of times may be chosen to 
process the request 

Any of various other factors regarding application con^onent performance other than those listed in 
Figure 9 may be used in other embodiments. 

5 Figures 10-12 illustrate an exemplary user interface of an administrative tool for adjusting load balancing 

factors such as those described above. Figiffe 10 illustrates a user interface screen for setting server load criteria 
values, such as those shown in the Figure 8 table. Administrators may adjust the weight for each factor as 
appropriate, in order to maximize performance for a particular application server. 

Note that the server load criteria values may be adjusted separately for each application server, as 6esm± 

10 Figure 1 1 illustrates a partial tree view of application servers in an application server cluster. In Figure 1 1, a single 
application server name, 'T^ASl^, is shown, along with various application conqxmcnts that run on the *14AS1** 
application server. For example, in the embodiment shown, various Enterprise JavaBeans™ that run on the 
^TIASI" server are shown under the "EJB" heading. The screens shown in Figures 10 aiul 1 1 may be coupled so 
that the server load criteria settings adjusted on the Figure 10 screen apply to the application server selected m die 

15 Figure 1 1 screen. 

Figure 12 illustrates a user interface screen for setting application con^onent performance criteria values, 
such as those shown in the Figwc 9 table. Administrators may adjust the weight given to each factor as 
appropriate, for each application component, by selecting the desired application con^Kment similarly as described 
above. The ^server load** vahxe shown in the Figure 12 screen may be a composite value conqmted using the 

20 Figure 10 server load criteria values. Thus, the load balancing criteria for each particular application component 
may be line-tuned using a variety of factors, in order to achieve maximum perfonnance for a particular system or 
application. The user interface may of course allofw default load balancing criteria to be speci fie d, may allow load* 
balancing criteria for multiple application components or multiple servers to be specified or copied, etc. 

Note that in Figures 10 and 12, nJscr-Dcfined Criteria** is selected in the *Tu>ad Balancing Method** field 

25 at the top of the screens, so that load balancing decisions are made by the application server load balancing 
services. The user interface may also allow the administrator to specify that load ba l a n c i n g decisions are made by 
dse client, e.g., the web server plug-in, as described above with reference to Figures 5 and 6^ by selecting a difierent 
option in this fidd. 

Referring again to Figure 7, the figure illustrates diat the load balancing services 330 in each application 
30 server 320 may communicate with the load balancing services of other application servers in the cluster in order to 
share information, such as the server load criteria and application conqxment performance criteria described above. 
In one embodiment, the load balancing services communicate using sundard User Datagram Protocol (UUP) 
muldcasting. 

In one embodiment, intervals for both broadcasting and updating load balancing informadon may be set 
35 using an administrative tooL Figure 13 illusirates one embodiment of a user interface screen for setting broadcast 
and update intervals. The *3ase Broadcast/Update Laterval** field refers to a base interval at which the load 
balancing service *^vakes tip** to broadcast information for its respective application server to die load balancing 
services of other application servers, to check to see whether any updated information was received fi^om other load 
balancing services, and to update the load balancing information with any received updates. The other intervals 
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shown in Figure 13 are relative to the base broadcast/update interval. For example^ the ^'Application Component 
Criteria** broadcast interval is two times the base interval, so that application component performance infoimation 
is broadcast every other time the load balancing service wakes up. Note that perfonnaitce information for a given 
application con^onent may be exchanged only between application servers hosting that application «oii^ncnt» in 
S order to avoid unnecessaiy netw or k tia fl i c . 

Figure 13 also illustrates fields for sening the broadcast interval server load information, and the update 
intervals for information described above, sucb as the server load value, CPU load. Disk Input/Output, Memory 
Thrash, and Number of Requests Queued. By adjusting the various broadcast and update intcrvak appropriately 
for a given application or system, the optimum balance between fresh load balancing data, server update overhead, 

10 and network traffic may be achieved. 

The information shared among application server load balancing sendees may be used to djynamically 
route a request received from a client to the '^est*' application server for processing the request. As ^w^-i— 
above, each client request may reference a particular application component. The decision as to which application 
server processes a request is preferably made based on the stored information regarding the particular application 

15 component Thus, at any given time, the '^est** application server for processing a request may depend on flte . 
particular application conxponent that the request references, depending on how the seiver load criteiia and 
application component performance criteria are rhnsrn^ as described above. 

If the load balancing service of die apphcation server that initially receives a request fiom a chent 
detcnnines that another application server is currently better able to process the request* then the request may be 

20 redirected to the other application server. As shown in the Figure 13 user interface, administrators may specify a 
maximum number of ^ops**, i.e., the maximum number of times that a request may be redirected before it is 
processed by the application server that last received the request The hop number may be updated in iht request 
informatibn each time the request is redirected. As the processed request is passed back to die cHem, eg., the web 
server phig^in, the cliem may record the application server that ultimately satisfied die. request so diat a similar 

25 future request would dien be sent by the client directly to that application server. 

'^cky*' Load Balancing 

Administrators may mark certain application components for **sticky** load balancing, meaning that 
requests issued within the context of a particular session that reference that application component are all proc es sed 

30 by the application component instance ruiming on the same application server. Some application comp o ne nts may . 
need to be marked for sticky load balancing, especially if the components rely on session information that cannot 
be distributed across application servers. Such situations may arise, for example, if an application is originally 
wrinen to run on one computer and is then ported to a distributed application server cluster enviromnent 

As an example of sticky load balancing, suppose that an application component called **SbopC8rt^ is 

35 duplicated across two application servers. Server A and Server B, for load balancii^. If a first client. Client 1 
performs a request referencing the ShopCart component, then the ShopCart instance ruiming on either Server A or 
Server B may be chosen to process the request, depending on the outcome of the load balancing decisions described 
above. Suj^se that the Server A ShopCart instance processes the request Then, if the ShopCan component is a 
component marked as requiring sticky load balancing, aiiy further requests issued by Client 1 that reference die 
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SbopCart component will a]so be processed by the Server A ShopCart component, regardless of the otbcr load 
balancing criteria. Requests by other clients referencing the ShopCart component may of course be processed on 
other servers, e.g^ on Server B, but then those requests too would "stick** to the application component instanrft 
where they were first processed. 
5 Figure 14 illustrates an exemplary user interface of a tool for enabling administrators to specify sticky load 

balancing for certain application components. Figure 14 illustrates a group of application c<m]ponent5 which, for 
exan^le, may be displayed by navigadng through a hierarchy fixe such as shown in Figure 11. The ''Sticky LB" 
cohunn of the user interface has a checkbox allowing sticky load balancing to be turned on for particular 
application components. 

10 Although some existing application server systems support sticky load balancing* tbc information required 

to dcicnnine the coixcct application server that should receive a given sticky request is often maintained on die 
server side. This may result in the client computer sending a sticky request to a first application server which then 
redirects the request to a second applicatson server that should process the sticky request To overcome diis 
inefiHciency, the client cQmputer(s) may instead be operable to maintain information regarding sticky requests so 

1 5 that requests are sent directly to the correct application server. 

In various erribodiments. the application server system may also enforce even distributioa of sticky 
requests. As noted, the initial request to a coinponem requiring stickiness may be made using normal load 
balancing methods, such as those described above. At any given time, these load balancing methods nay 
determine that a particular application server is the "bcsT server to process a request Thus, it may be possible that 

20 a particular applicaticm server receives a large batch of initial requests referencing sticky conqxments. Since each 
session that sent an initial sticl^ request to the application server is then bound to lhat ^ipfication server for 
subsequent requests, the result may be a decrease in application performance over the long tenn. 

Thus, the system may track information regarding the number of sticky requests that are currently bound 
to each application server and may force the sticky requests to be distributed roughly evenly. In one embodiment, 

25 administrators may assign a weight to each application server, such as described above, and the sticky requests may 
be distributed in proportion to these weights. 

Graceful Distribution 

Some existmg application server load balancing systems use a *Svinncr-take-air strategy, in which all 
30 incoming requests at any given time arc assigned to the calculated '*bcst- appbcation server. However, experience 
m the application server field has shown that the rcsuh of such a strategy may be cyclic pattern in which, at any 
given time, one application server may be under a heavy load, while other servers are mostly idle. This problem 
may arise in pan from load balancing information being shared at periodic intervals, rather than in real time. 

Thus, in various embodiments, ^gracefiiT load balancing methods may be utilized, in which the "teT 
35 application server at a given time moment or interval, as defined by criteria such as described above, is assigned die 
largest nuniber of incoming requests, while other application servers, or a subset of the other application servers, 
are still assigned some of the incoming requests. Such graceful load balancing may be performed using any of 
various methods. As a simple example, a weighted random distribution algorithm may be used. For exan^le, for a 
cluster of application servers of size L, a random number between 1 and L may be generated, where the generated 
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number designates the number of the application server to assign the request to, and where 1 represents the current 
^est** apph'cation server to process the request and L represents the application server at the other end of the 
spectrum. Thus, the random number is generated in a weighted manner, such that the probability of choosing a 
server number diminishes going from 1 to L. The resulting request distribution pattern may then appear similar to a 
5 y 1/x graph pattern. 

This type of graceful request distribution may be applied at various levels, depending on a particular 
application or system. For example, as described above, one general load balancing approach that may be used is 
to leave the distribution decision to the client e-g*» by tracking the responise times as seen Irom each application 
server. Thus the client, eg., the web server plug-in, may rank the application servers by their response times and 
10 '^gracefully'* distribute requests among the application servers, thus helping to maintain an even work load among 
the application servers at all times. On the other hand, if load balancing decisions are made by the load balancijQg 
services of the application servers theinselves, as described above, then these load balancing services may eixq>loy a 
type of graceful distribution algorithni. 

15 Request Failovcr 

As described above, requests may be brokered from a client such as a web server to an appltcaticm server. 
In some instances, requests may fail, e.g., due to a lost connection berween the client and the application server, an 
application server failure, etc. Depending on the commum'cation protocol used to perform the request, requests 
may tnne out afler a certain time period.' For exan^lef'a TCP/IP-based request inay timeout after a configurable 
20 time period. The timeout time period may or may not be configurable, depending on the cn virouu iem, such as Ac 
particular operating system. Note that the typical default timeout period may be larjgc, c^. 30 minutes. If a fcqucst 
fails, e.g. due to a server power failtire, other requests may be forced to wait while ihs requesting ducad waits for a 
response that win never come. 

Figure 15 is a flowchart diagram illustrating one embodhnent of a method that may overcome dkis 
25 problem. In step 470, the client con^uter sends a request to an application server using a custom wire-level 
communication protocc^ The use of such a protocol may enable the cliem con^uter to detect aiid recover fiom 
failed requests, as described below. Note that this custom protocol may be in9>lemented as a protocol using various 
standard commtmication protocols, such as the TCP/IP protocol 

In one embodiment, each request is performed by a separate thread running in the client computer. In step 
30 472, the requesting thread sleeps, using standard operating system techniques. 

As shown in step 474, the requesting thread may periodically wake up to poll the application server for 
information regarding the status of the requesL The time interval for which the requesting thread sleeps between 
performing these polling operations may be configurable by system administrators via a provided user interface. In 
one embodiment, the requesting thread may poll the application server by sending a User Datagram Protocol tUDP) 
35 message comprising information identifying the request to the application server. For exaniple, each request sent to 
the application server may comprise a request ID enabling both the client computer and the application server to 
track the request. Upon receiving the UDP message, the application server is operable to use the request 
infonoiation to determine the status of the identified request and inform the requesting thread of the request status. 
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In step 476, ihc lequcsting ihrcad dctcnnines whether a response to the poll message was received from 
the application server. For cxan^lc. the requesting thread may simply wait for a response for a pre>set, relatively 
short time intervaL 

If a response to the poll message is received, then in step 478, the requesting thread analyzes the response 
5 to determine the current status of the request, as informed by the application server. If the request is currently being 
processed by the application server, then the requesting thread may singly return to sleep* as shown in step 480. 
Note dial this check can thus not only detect failed requests, but may also enable the application server to process 
requests that take a lot of time to process and that would result in request timeouts if standard communication 
protocols were used. 

10 If ihc request is not currently being processed by the application server, then the request failed for some 

reason, c.g^ due to a broken network connection, an application server error, etc. As shown in step 482, die 
requesting thread may then re-send the request and then re-perform steps 472 - 488. The requesting thread may be 
operable to attempt to send the request to the same application server a certain number of times before conchidiBg 
that requests to that application server are failing for some reason and then ancrapting to send the request to a 

15 different application server, if the application server is pan of an application server cluster. 

If no response to the poD message was received in step 476, then in step 484, iht requesting tfxread may 
send the request to another application server, if the application server is pan of an application server chistcr. 

The client computer preferably maintains information regarding the current state of each application server 
in the chister. In step 486, the application server that did not reply to the polliiig message may be marked as 

20 "ofiOine*' so that further requests will not be sent to liiat application server. 

As shown in step 488, die client conqniter may be operable to periodically poD the failed application 
server to determine whedier the application server is online again. For example, the cliem conqniter may run a 
thread that maintains the application server status information and periodically polls the application servers mariced 
as being ofHine. If so, then the application server status information may be updated so that the application server 

25 is placed back in rotation to receive client requests. 

Class Reloading 

In various cixibodiments, an application server may allow some application components, such as Java 
Scrvlets™ and JavaServer Pages™, to be dynamically reloaded while the server is mnning. This enables 
30 administrators to make changes to an application without restarting. Having to stop/restart an application is, of 
course, a serious problem in many situations. As described below, administrators may specily which classes v^aA 
are to be considered "Versionable" or dynamically reloadable. 

A versioning scheme is described with the following design points: 
35 • Not all classes arc versioned by default. A distinction is made between •Versionable* and "non-versionable" 
classes. As described above, versioning classes bydefauh often suffers from various drawbadcs. 
• Version all major components - If client's classes arc "Known" (see definition below), then versioning will 
happen automatically. 
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• User. Configurable > For ihose client classes that are not "Known**, the client may perform additional steps 
diuing deployment time to set up environmental variables. Users can then explicitly specify additional 
application-level cbsses that should be venionable. 

• Interfaces are preferably not versioned to avoid runtime conflicts that may be caused by dynamically updating 
5 interfaces. 

The user may designate some classes as system classes. System classes preferably arc not versioned. Certain 
classes may be designated as system classes by default 

Under the versioning scheme described herein, a user may control class versionability/reloadability by 
10 using the following environment entries, which may be implemented as registry entries. A user interface may be 
provided for managing these settings. 

• GX_ALL_VERSIONABLE 

A noih-zero value for this entiy causes all classes to be coruidered versionable. The default vahie is zero. Ibis 
15 entry may be used for backward compatibility with other sjrssems. 

• GXJVERSIONABLE 

This entry comprises a semicolon-delimited list of classes that are to be considered by the system as versionable 
classes. By default, die list is enopty. 
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• GX_VERSIC»IABLE.IF_EXTENDS 

This entry con^rises a semicolon-delimited list of classes. If a user's class extends a class in this list, then the 
user's is considered to be. versionable. The default class list contains the javax.servleLGcnereitScrvlet and 
javax.servletilttpScrvlet classes. Users can append additional classes to this UsL 

• GX_VERSIONABIX_IF_IMPLEMENTS 

This entry comprises a semicolon^delimited list of interfaces. If a class implements an interface in this list, then the 
class is considered to be versionable. The default interface list contains the javax.servlet.Servlet interface. Us 
can append additional interfaces to this list . 



• GX_TASKMANAGER.PERIOD 

A timed thread wakes up periodically io check for any classes that may need to be reloaded. If a user modifies a 
versionable class, the thread may instantiate a new classloader to dynaim'caDy reload the modified class. The $leq» 
time period for the thread may be set by setting the vahie of the GX_TASKMANAGER_P£RICn) registry entry. 
35 The default vahie for the GX_TASKMANAGER_PERIOD entry is -IC* seconds. 
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Known gasses 

The class loader may determine whether a class that needs to be versioncd is "known" based on hs 
inheritance tree. The class loader checks for the class's super classes and implemented interfaces to determine 
whether they are in the GX_VERS10NABLE_IF_EXTCNDS or GX_VERSIONABlJE_IF_IMPliMENTS lists, 
respectively. If there is a match, tbra the derived class is considered TtDOwn". 

This system works particularly weO in siteations where aO or most classes diat need to be runtiine- 
versioned are subclasses of a relatively smaU set of super classes. For example, in die case of seivlets. aU seivtet 
classes that are versionable may be subclasses of the javax.servIet.GeneiicServlet or javax-servletJJttpSeivlet, or 

they may an iiiq)l"«>">* j"^-*"^''*-^"^'** "*^*'** 

In one embodiment. JSP files are versionable by default They can easily be identified not by their 

inheritance, but by their file name extension of ".jsp. 

For any given class name that the classloader is asked to chedc, the classknder may locale the class file in 
the file system, then parse the cbssffle in order to identiJy its immediate superclass as well as all the inteifices 
toptanented by the class. It is importam to note that dining the chedc, the class loader may only examine the 
classfile in the file system to determine versionabflity and may not actually load the dass into the system in oider 
to examine it. Due to the cache stickiness of the JVM concerning loaded ctosses, previous experiments have shown 
that it is usually a bad idea to load a class to detenmne the versionabiUty of it. Thus the "normal" way to make 
one's dass versionable is to extcndTimplement those dasses specified in the above-mentioned registry entries. 

Issuing a Warning While Sc ^'H^f; Von-vcrsionable Classes 

One potential problem occurs when an object diat is being serialized in the session/state module refers to 
anodier object whose ctess is versionable. In order to detect potential errors downstream, die session/state code cma 
be modified so that when a client session is being serialized, a subclass of die stream ch»s is ins tantiated. I n dus 
subclass an inquiry is made regarding eadi cUiss diat is being serialized. If sudi • class is detenmned to be 
•versionable- (as defined by the above-mentioned mles). die system may issue or log a warning. TTiis detecdon 
mediod works widi beans and senflets which inclement die serializable interface. 

Any cadie widiin die system which may contain versionable classes (e.g.. EJB container, servlets. JSPs) may 
provide an interface so that a class can be purged ftom the cache on a per-class basis, e*. by specifying die name 
of the class to purge. Eadi component that pools versionable objects should provide a medunism enabling die 
classloader to inform diem diat die class versions for diose objects have changed, and d»t die pool should dms be 
purged. For example, an application server Java™ Servlet runner or Enterprise JavaBeans™* container may 
implement such inieifaees. 

hnolementation Details 

hi one embodiment, diere are diree different cbss loaders working inside die system at any given time: 
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• The Primordial Qassloader (PCL) - used to load any core classes and any native code using "workaround" core 
classes 

• Engine ClassLoader (£CL) • A dassloader (iliore precisely a series of engineClassloaders) used to load all 
vcrsionable classes 

5 • Non Vcrsionable Oassloaders (NVCL) - A classloader used to load all non*versionable classes. There is only 
one such dassloader, which is preferably never repbced. 

A loadClassO call may first determine whether the class in question is versioixable or not, and then use die 
appropriate dassloader to load the class. 

10 

Figures 16—17: Versioning Flowcharts 

Figure 16 is a flowchan diagram illustrating one embodiment of a method for dynamically discoveiiiig 
and reloading classes, based on the descriptions above. 

In step 400 of Figure 16, a timed thread wakes up to check for modified classes. It is noted dial it may 
15 only be necessary to check for changes in certain classes, since classes are not yersioned by default In one 
embodiment, the list of versionable classes may be determined once, e.g. using the method shown in the'^gore 17 
flowchart, and the list may be reused by the timed thread each time the thread wakes up. If an administrator 
* changes the vcrsionability settings, the list may be updated Each class in the list may be checked for modifications 
in any way appropriate for a particular environment. For example, the application server may record the date and 
20 time of the class file when the class is first loaded and may check to determine whether the file has since been 
modifiodL 

As shown in step 404, if no modified versionable classes are found, the diread may sinq>ly retum to slee|i. 
If one or more modified classes are fotmd, then steps 406 -.4 10 may be performed for ead modified -class. 

In step 406, a new dassloader is instantiated. 
25 In step 408, the clBSsloadcr instantiated in step 406 is used to reload the modified class. 

In step 410, the modified class may be purged from any caches maintained by the application server. As 
described above, any application server components that maintain caches may provide interfaces for pivging a 
modified class fiom the carfie. 

It is noted that Figure 16 represents one embodiment of a method for dynamically reloading classes, and 
30 various steps may be added, omined, combined, modified, reordered, etc. For exan^Ie, in some environments it 
may not be necessary to instantiate a new dassloader for each class to be reloaded. 

Figure 17 is a flowchart diagram illustrating one embodiment of a method for determining whether a class 
is versionable, that is whether the class should be dynaimcally reloaded when modified. 

In step 420 of Figure 17, it is determined whether the class name is listed in the GX.VERSIONABU lisi 
35 (described above). If so, then the class is versionable. 

In step 422, it is determined whether one or more of the class's superclasses are listed in the 
GX_VERS10NABIX_IF_EXTSNIDS list (described above). If so, then the class is versionable. 
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In step 424. it is detcimined wheiher one oi more of the interfaces implemented by the class are listed in 
the GX_VERS10NABLE_IF_1MPLEMENTS list (described above). If so, then the class is versionable. 
Otherwise, the class may not be versionable. Modifications made to non-veisionable classes nay be ignored wbOe . 
an application is running. 

5 It is noted that Figure 17 Represents one embodiment of a method for determinii« whedw a class is 

versionable. and various steps may be added, omitted, combined, modified, reordered, etc. For exan^Ie. steps 420 
422 may be peifonned in any order desBcd. 

It is noted that an appKcatioa server utilizing the methods described above witfi reference to Figures 16 
and 17 may advantageously not consider interface chases to be versionable by default, thus helping to enforce 
10 inter&ee contracts between cona|ioneBti. 

Atomic gass-Loadittg 

It is often desirible to update a set of classes atonrically, to have M dynamk reloading charges for 
each class in the set take effect at the same time. Without an abiKty to perform atomic class-loading, errors may 
15 resnli when classes are dyrtamically reloaded. 

Figure 18 is a flowchart diagram iDustrating one embodiment of a method for perfonaaing atomic clasa- 
loading. As shown in step 440, an administrator may speciiy a set of cbss files to be treated as a "bundle-. For 
example, the application server may provide a user interface for managing and deptoyiAg dass files ftoiD a 
developrneni environment to the runtime system. Ibis user interface may enable the administrator to define a edit 
20 a ch« bundle. In one embodiment, a componem referred to as the -depltqrer manager- provides the^ 

In step 442. the administrator requests the application server to d^loy the ctess bundle qiecified in step 

440^ e.gn "*^E the user intet&ce described above. 

In response to the adininistrator's request in step 442. the deployer manager may obtains a lode referred to 

as the -dinyOassListLock- in step 444. TTie dirtyClassListLock may be implemented in tay of various standard 
25 ways, eg, as a semaphore. TTie timed thread descril>ed above that dynamically discoven and reloads modified 
versiomiblc ctosses may also require the dirtyOassListLock. TTius. While the deptoycr manager holds the 
dirtyClassListLock. the timed diread may not proceed. 

After obtaining the dinyClassListLock. the deployer manager copies all class files in the bundle to their 
appropriate runtime locations in the file system in step 446. 
30 The deployer manager then releases the dirtyClassListLock in step 448. 

As shown in step 450. the timed thread canihen resume its normal chedc for mo^fied classes. Uma, all 
the new classes ftom the bundle are processed and loaded together. 



JavaServer Pages™ Caching 

35 This section provides an overview of JavaServer Pages™ (JSP) technology and describes a caching system 

and method for JSP component responses. JavaServer Pages™ (JSP) is a Java™ platform technology for bmlding 
applications streaming dynamic content such as HTML, DHTML, XHTML and XMU JavaServer Pages is a 
Standard Extension that is defmed on top of the Servlel Suindard Extension. JSP 1.0 uses the classes from Java 
Servlet 2.1 specification. For more information on JavaServer Pages™, please refer to the JavaServer Pages™ 
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SpeciTicauon, Version 1.0, available from Sun Micros>'5teins, Inc. For more infonnadon on Java scrvlets, please 
refer lo ihc Java Scrvlel 2.1 Specification, available from Sun Microsystems, Inc. 

A JSP component is a lext-based document that describes how lo process a request to create a response. 
The description intermixes template data with some dynamic actions and leverages on the Java''** Platform. In 
5 general, a JSP component uses some data sent to the server in a cliem request to interact with information already 
stored on the server, and then dynamically creates some content which is then sent back to the client The content 
can be organized in some standard format, such as HTML, DHTifl-, XHTML, XML, ctc^ or id some ad-hoe 
strucnired text format, or not at alL The following segment ilhistrates a simple example of a JSP con^oneol: 

10 <htnB> 

<% if (Calendar.getIiistance0.get(Calendar.AM_PM) = Calendar JVM) {%> 
Good Morning 
<% ) else ( 
Good Afternoon 
15 <%}%> 

</h tiTit> 

The exan^le above shows a response page, which is intended to display cither •Xjood Morning*" or **Good 
afternoon" depending on the moment when the request is received. The page itself contains several fixed ten^Iate 
20 text sections, and some JSP elements enclosed in 9^** brackets. 

A JSP component may be handled tii application servers by various types of JSP *^giiirn. For example^ in - 
one embodiment, die Java Server process 204 shown in Figure 3 may manage or act as tiie JSP j^^c^ H&e JSP 
engine delivers requests from a client to a JSP conqxment and responses from the JSP con^onent to the jht. 
semantic model underlying JSP con^nents is that of a Servlet: a JSP con^nent describes how to create a 
25 response object from a request object for a given protocol, possibly creating and/or using in the process some other 
objects. 

All JSP engines must support HTTP as a protocol for requests and responses, but an engine may also 
support additional request^esponse protocols. The default request and response objects aie of type 
Ht^ServletRequest and HttpSeivlctRcsponse, respectively. A JSP component may also indicate how some evcott 
30 are to be handled. In JSP 1 .0, only init and destroy events can be described: the first time a request is delivered to a 
JSP component a jspInitQ method, if present, will be called to prepare the page. Similarly, a JSP engine can reclaim 
the resources used by a JSP component at any time that a request is not being serviced by the JSP component by 
invoking first its jspDestroyO method; this is the same life*cycle as that of Servlels. 

JSP con^nents are often implemented using a JSP translation phase that is done only onee, followed by 
35 some request processing phase that is done tmce per request The translation phase usuaDy creates a diat 
in^lements the javax.5ervlet.Servlet interface. The translation of a JSP source page into a correspondii^ Java 
implementation class file by a JSP engine can occm at any time between inirial deployment of the JSP con^ncnt 
into the runtime environment of a JSP engine, and the receipt and processing of a client request for the target JSP 
conq>onenL A JSP component contains some declarations, some fixed template data, some tperhaps nested) action 
40 instances, and some scripting elements. When a request is delivered to a JSP component, all these pieces are used to 
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create a response object that is then rcwined to the client Usually, the most imponant pan of this response object is 
the result stream. 

A JSP component can create and/or access some Java objects when processing a request The JSP 
specification indicates that some objects are created in^licitly. perhaps as a result of a directive; other objects arc 
created explicitly through actions; objects can also be created directly using scripting code, although this is less 
common. Tht created objects have a scope attribute defining where there is a reference to the object and when diat 
reference is removed. 

The created objects may also be visible directly to the scrq>ting elements through some scripting-level 
variables (see Section 1.4.5, 't)bjects and Variables). Each action and declaration defmes. as part of its semantics, 
what objects it defmes, with what scope attribute, and whether they are available to the scripting elements. Objects 
are always created within some JSP coniponent instance that is responding to some request object JSP defines 
several scopes: 

- page • Objects with page scope arc accessible only within the page where they are created. AD references to such 
an objea shafl be released after the response is sent back to the client from the JSP con^nent ot the request is 
forwarded somewhere else. References to objects with page scope are stored in the pagecontext olyject 

- request - Objects with request scope are accessible from pages processing the same request where they were 
created. AU references to the object shall be released after the request is processed; in particular, if the request is 
forwarded to a resource in the same runtime, the o«ect is stiU reachabfe^ 

are stored in die request objcd 



. Objects with session scope are accessible from pages processing requests that are in the same sessicm as 
the one in which they were created. It is not legal to defme an object with session scope from within a page is 
25 not session-aware. All references to the object shaU be released after the associated session ends. References to 
objects with session scope are stored in the session object associated with the page activation. 

- application - Objects with application scope are accessible from pages processing requests that are in the same 
application as they one in which they were created. AU references to the object shall be released when the nmtime 
30 environment reclaims the ScrvletContext Objects with application scope can be defmed (and reached) from pages 
that are not session-aware. References to objects with application scope are stored in ^ application object 
associated with a page activation. A name should refer to a unique objea at afl points in the execution. i.e. aO die 
different scopes reaDy should behave as a single name space. A JSP implementation may or not enforce diis rule 
explicitly due to performance reasons. 



Fixed Template Data 

Fixed template data is used to describe those pieces that are to be used verbatim either in the response or as 
input to JSP actions. For exan^le, if the JSP component is creating a presentation in HTML of a list of, say. books 
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that match some search conditions, the template data may include things like the <ul>, .<Ai>, and something like 
<li>The following book^. . 

This fixed template data is wrinen (in lexical order) unchanged onto the output stream (referenced by the 
implicit out variable) of the response to the requesting cHeat 

5 

Directives and Actions 

JSP elements can be directives or actions. Directives provide global information that is conceptually valid 
independent of any specific request received by the JSP con^onent. For example, a directive can be used to 
indicate the scripting language to use in a JSP component Actions may, and often will, depend on the details of the 
10 specific request received by the JSP con9)onent If a JSP is implemented using a con^ikr or transktor, die 
directives can be seen as providing information for the conq;)ilation/translation phase, while actions aie infoimatioD 
for the subsequent request processing phase. An action may create some objects and may make tfaem available to 
the scripting elements through some sorq>txng-specific variables. 

Directive elements have a syntax of the fonn 

15 <%<§ directive .,.%> 

There is also an alternative syntax that follows the XML syntax. 

Action elements follow the syntax of XML elements^ Le. have a start tag, a body and an end tag: 

<knytag atirl»**attributB value** ^ 
body 

20 <;Anytag> 

or an empty lag . 
<niytab attrl'='*'attribute value** 

A JSP element has an element type describing its tag name, its valid attributes and its 
25 semantics; we refer to the type by its tag name. 

Applications and ScrvletContexts 

In JSP 1.0 (and Servlet 2.1) an HTTP protocol application is identified by a set of (possibly disjoint) URLb 
mapped to the resources thereiiL JSP 1.0 docs not include a mechanism to indicate that a given URL denotes a JSP 
30 component, although every JSP implementation will likely have such mechanism. For example, JSPs may be 
identified by a -.jsp" file extension. In most JSP in^lenientations, a JSP component is transparently translated into 
a Servlet class iile through a process involving a Java^ compOer. 

The URL set described above is associated, by the JSP engine (or Servlet runtime environment) wiflj a 
unique instance of a javax^servleLServletContcxt Servlets and JSPs in the same application can share this instance, 
35 and they can share global application state by sharing objects via the ScrvlctContext setAttributeQ* gctAttributeQ 
and removeAtiributeO methods. We assume that the information that a JSP coniq)onent uses directly is aD 
accessible from its corresponding ServletContexL 

Each client (connectioii) may be assigned a session (javax.scrvlet Jittp JittpScssion) imiqucly identifying it 
Servlets and JSPs in die same "application** may share global session dependent state by sharing objects via the 
40 HnpSession putVahieQ. geiValucQ and remove VahieQ methods. Care must be taken when sharing/manipulating 
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such state between JSPs and/or Servlcts since two or more threads of cxectition may be simultaneously active 
within Servlets and/or JSPs. thus piopei synchronization of access to such shared state is required at aU times to 
avoid unpredictable behaviors. Note that sessions may be invalidated or expire a any time. JSPs and Seivlets. 
handling the same jaVax^leuSeiyletRequest may pass shared state using the ServletReipiest setAttrilwtea 
5 getAttributeOandremoveAttrfljuteOroediods. 

Translation Phase 

A typical implementation works by associating with the URL deiioting the JSP a JSPEn^neSeivlet This 
JSPEngineServlct is responsibk for determining if there already exists a JSP component implemeniatioD ckss; if 
10 not it win create a Seivlet source description implementing the JSP component, compOe it into some bytecodes and 
a«a load them via a Classlxwder instance; most likely never touching the file systcm^ Once the JSP component 
implementation class is located, the JSPEngineServlct will perform the usual Scrvlct initialization and wiD deliver 
the request it received to the insumce. The JSPEngineServlct Servlet is instantiated in a ServletContcxt that 
icpiesents the original JSP object 

IS 

JSP Response Caching 

This section describes how response caching may be enabled fat a system implementing JSP technology. 
Although oi» use of JSP is to create dynamic responses, such as dynamic web pages for disphiy. it wiD be 
appreciated that response caching may be desirable in many siwations. For example, data used to create a response 
20 may change oiJy once an hour, and thus a response created from the data could be cached and reused mncb of the 
time. In particular, cachmg may often improve the performance of running composite JSPS. that is JSP files wfaidi 
indude other JSPs. 

For eadi JSP conqwnent. the criteria for reusing a cached version of the response may be set. by 
incfarding a method caD in the JSP file, such as •^etCacheQite.iaO-. The setCacheClriteriaO method may be 
25 overloaded to aUow for various arguments to be passed in. in one embodiment the setCacheCWteriaO method 
coD^rises the foUowiiig signature valiants: 

setCacheCriteiia(int sees) 

where the 'sees' parameter indicates the number of seconds for which the cached response should be considered 
30 valid. In this variant, no other criteria are specified. Thus, the JSP response is unconditionally cached. If •Secaf is 
set to 0. the cache may be flushed. 

set(^cheCriteria(int sees. String criteria) 

where the 'sees' parameter is the same as described above, and the 'criteria' parameter specifies the criteria to use 
35 in determining whether or not the cached response may be used to satisfy a request Caching criteria are discussed 
in more detail below. 

setCacbeCritera(iDt sees, int size. Siring criteria) 
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where ihe 'sees' and 'criteria* paramcicrs arc the same as described above, and <bc *si2e' parameter specifies the 
size of the buffer for the cached response. 



Caching Criteria 

5 The interface for calling JSPs is based on the interface javax.servletJlequestDispatchcr. This interface has 

two methods, forwardQ and inchideQ, where the fonner acts like a redirect, i.e. tt can be called only once per 
request, whereas the latter can be called multiple times. For example, a forward call to Tjsp' may look like: 

public void service(Htq>ServletRequest rcq, HttpServletRcsponsc res) 
10 throws ServIetException, lO&cception 

{ 

res.setContcntType("tcxt/htnal"); 
RequestDispatcher dispatcher » 

gctServletContextO-getRequestDispatcheiCfjsp"); 
15 dispatcher.forward(req,res); 

) 

JSP components often accept and use arguments themselves. Arguments to the JSP file can be passed as part of the 
URL of the file, or in atvibutes using ServlctRequcstsctAtnTbuieO. These argument names and vahies can be used 
20 to set caching criteria and to check whether a cached response can be used to satisfy a request 
For exanqple, in an include caU to *fjsp\ arguments *age' and 'occupation' can 1^ 



public void servicc(HttpServletRequcst rcq, HtqjServletResponse ICS) 
dirows ScrvletExcepnon, lO&cceptiQQ 

25 { 

les-setCbntentTypeCtext/httnT); 
RequestDispatcher dispatcher* 

getScfvlctContcxt0.gctRcquc$tDispatchei("fjsp?ageM2'0; 
rcq.setAttribute("occupation'*,''doctor'0; 
30 dispatcheranclude(req,rcs^ 

) 

Within the f.jsp component, a setCachcCriteriaO suterocnt may then set the response caching criteria based on the 
vahies of the 'age' and 'occupation* arguments. For example, the f.jsp component may include the statement: 

35 

<% setCacheCriteria (3600, ''age>40 & occupation=doctor^; %> 

to indicate that the response should be cached with an expiration time of 3600 seconds, and that the response may 
be used to satisfy any requests to run the fjsp conq>onent with an 'age* argument vahie of greater than 40 and an 
40 'occupation' arginnent value of **doctor^. 

Of course, the JSP component may contain ntmierous setCacheCriteriaQ statements at different points in 
the JSP file, e,g. at different branches within an 'iT statement, each of which may set different caching criteria. 
Depending on the arguments passed in to the JSP and other dynamic conditions, a particular set of caching criteria 
45 may then be set for the response currently being generated. 
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In the example above, the dispatcher may use the values of the *age* and 'occupation' arguments to 
detennine whether any cached JSP responses can be used to satisfy a request instead of re-running the JSP and re- 
generating a response from it For example, a request to 11 jsp appearing as: 

5 res3etContcniTypc("tcxt/html"); 

RcquestDispatcher dispatcher » 

gctScrvlciC6DtcxtO.geiReques!Dispatcbcr("f.jsp?agc«39&occupation=doct0r*); 
dispatcheribrward(req» res); 

20 would not be satisfied by a response previously generated from the f.jsp JSP which had set its caching criteria with 
the statemcot 

<% setOcheCriteria (3600, '^ge>40 & occupation^^octoT); %> 

15 because the age argument is not within the range specified as valid for this cached response. However, this same 
request may be satisfied by a response previously generated from the f.jsp JSP wfaidi had set its caching criteria 
wilh the statement: 



20 



<% sctCacheCriteiia (3600» "agc>35 & occupation=HJoctoO; %> 



Hence the cache may be checked before nmning a JSP, and if a valid cached response is foimd, then the dft^tchcr 
may return the response nmnediatefy. 

A cached JSP response may be stored in various ways. In one embodiment, a response is stored as a byte 
array (byteQ in Java). Each cached response may have an associated criteria set stored, indicating when tfie 

25 response is valid. The criteria may include an expiration time, e.g. a time in seconds to consider die cached 
response valid. After this expiration time passes, the response may be removed from the carhr . The critaia may 
also include a set of constraints, where each constraint specifies a variable and indicates the valid values whasik Ae 
variable value must match in order to satisfy the cache criteria. As described above, a JSP response may set tfiese 
cache criteria progranunatically using a setCacheCriteriaO statement. For example, the SctCacheCritcria (3600, 

30 **ag035 & occupation=doctor*0 statement appearing above specifies an expiration time of 3600 seconds and a 
constraint set with two constraints: 

'age' > 35 and 
•occupation* « •*docini^ 

35 

In various enibodimentsl different types of constraints may be specified, including the following types of 
constraints: 

- X (e.g., SctCacheC:riteria (3600, •^•)) 

40 meaiung that *x* must be present either as a parameter or an attribute. 

28 



eNSDOCtO- «WO pi ia227A2.L> 



wo 01/19227 



PCT/US00/220S5 



- X = vl I v2 U- 1 vk (e.g^ SetCacbeCriieria (3600, "x^docioijniiise")) 

meaning that *x* must match one of the strings listed. For each string, a regulai expression may be used, where 'x* 
is said to match the string if it meets the regular expression criteria given. 

5 -x = low -high (c.g.,SctCacheOiteria(3600,'^=20-50^) 
meaning that *x' must match a value in the range of low <« x high. 

Various other types of constraints may also he specified, such as the use of mathematical **greater than/less thm'* 
symbols, etc. for ensuring that an argimient falls within a certain range. Also, constraints may be specified based 
10 on dynamic user session data, such as the current value of a user's shopping cart, user demographic information, 
etc 

Figure 1 9 - Flowchart 

Figure 19 is a flowchart diagram illustrating one eiribodiment of a method for enabling JSP response 
15 caching, based on the above descr^tion. In one embodiment, the JSP engine manages the pt o ce&s .iDustiated in 
Figure 19. 

In step 600 a request referencing a JSP con^nent is received. The request may, for example,, have an 
associated URL that references a JSP. The JSP engine may receive the request from another service or camponeat 
running on the application server or directly from a client computer. 

20 In step 602 the JSP response cache is cbedced to determine whether a response in the cache satisfies the 

request Ibe JSP response cache may be iinplemented in any of various ways, and responses and their associated 
criteria sets may be represented and stored in the cache in any of various ways. As noted above, in one 
embodiment, a response is stored as a byte array. 

As described above, the information received along with the JSP request may include various attributes, 

25 such as variable name value pairs. In step 602, these attributes may be compared against the criteria set for ea^ 
cached response. The conr^arisons may be performed in various ways, depending cm what' types of matching 
criteria are supported in a particular embodimem and how the criteria are stored. The JSP response cache is 
preferably organized to enable an efficient criteria-matching algorithm. For example, the cache may be organized 
based on session context such as user ID or role, security context, etc 

30 In step 604 it is determined whether a matching cached response was found in step 602. If so, then in step 

606 the cached response is immediately returned without running the referenced JSP. For exan^Ie, if responses are 
stored as byte arrays, then the byte array conesponding to the response whose criteria set matched the request 
attributes may be retrieved and streamed back. 

If no matching cached response was found, then in step 608 the referenced JSP may be called. The JSP 

35 engine then executes the JSP, using the attributes included in the request As described above, depending on the 
dynamic conditions of the execudon, different SetCacheCriteriaQ method calls with different arguments may be 
encoimtered during the JSP execution. 

In step 610 it is determined whether the JSP response should be ca che d. For exampte, if no 
SetCacheCriteriaO method calls were encountered during the execution of the JSP, then the response may not be 
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cached. Also, in various embodiments, the applicatioii server may enable administrators to utilize a user interface 
to specify for which application server components the output should be cached. This information may.also be 
checked in step 610. 

If the JSP response should not be cached, then ihe response may simply be returned in step 616, eg., by 

streaming back the response. 

If the JSP response should be cached, then in step 612 a response entry to represent the response may be 
created, and in step 614 the JSP response may be stored in the response entry. As noted above, response entries 
may be implemented in any of various ways. As shown in step 612. the appropriate criteria set, as defined by die 
arguments of the SetCacheCriteriaQ method calls encountered during the JSP exccu^on may be associated with die 
response entr^r. Note dat. if multiple SetCacheCriteriaQ mcdiod calls are encountered, Oien multiple response 
entries conesponding to the method calls may be created. 

In step 6 1 6 die JSP response is then retunod. 

It is noted that Figure 1 9 represents one embodiment of a method for enabling JSP response caching, and 
various steps may be added, omineil. combined, modried. reordered, etc. For example, in one cmbodimeBl, m stqi 
nay be added so that die JSP file referenced by the request is checked on die file system to determine whedicr the 
file has been modified since die JSP was loaded or since die associated responses were cached. If so, dib associated 
responses inay be fhishcd from die cache, and die JSP inay be reloaded and caUei 

Comoosite JSPa 

Widi die support described above, composite JSPs, dutt is JSP files which inchide odier JSP*, can be 
efficienUy implemented There may be one top-lcvd fhunc, emitted eidicr ftom a scn^ 

issues one or several RequesiDispatcherinchide calls for odier JSP files. Each of die inchided JSP files n»y 
generate response content Some of diese JSP fdes may aheady have associated respimses cached, and odien mey 
not. For each cached response tirnc, die associated expiration time inay vary. 

For exanq}lc. here is a 'compose.jsp' JSP listing: 



<% setC8cheCriteria(l); %> 
<HTML> 

30 <HEAI» 

-^nTIJE>conipose (JSP)</nTLE> 

</HEAD> 

<BODY> 

<H2>Channel 1</H2> 

35 

RequestDispatchcr di^ « 

getScrvletContcxtO-gctRequestDispatcherCcl 

disp include(request. response); 
%> 

40 <H2X3iannel2<;/H2> 

disp •= gctScrvleiConlext0.getRequeslDispatchcr<"c2.jsp'0; 
disp.include(request, response); 
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%> 

<mODY> 
<«TML> 



5 where 'cl.jsp* appeals as: 



<% setCacheCnteria( 1 0); %> 
<^i|> 

<li>Today ... 

10 

<Ail> 



and 'c2.j^* apjpcaxs as: 



15 <%sctCacheOiteria(2,"x-);%> 
<ut> 

<li>Toiiioimw ... 

20 

Note that nehfaer *cl .jsp* nor *c2.j^* emits coxiq>lete HTML pages, but rather sn^pets thereof, and dmt each file has 
Its own caching criteria. 



A helper function for including URIs may be provided, so that, for exan^le, the above-listed 'compose.jsp* file 
25 may appear as: 



<% sctCacheCriteri8(l); %> 

<HTML> 

<HEAD> 

30 <Trn-E>convose (JSP)</nTLE> 
</HEAI>> 
<BODY> 

<ll2>Channel 1</H2> 
<% 

35 includeURl('^cl.jsp'',reque$t,response); 
%> 

<H2>ChattncI 2</H2> 
<% 

includeURI(**c2.j5p",request, response); 
40 %> 

<mODY> 
</HTML> 

instead of as the listing shown above. 

45 

. Events 

In various embodiments of application servers, developers can create and use named cveiil&. The tenn 
event is widely used to refer to user interface actions, such as mouse clicks, that trigger code. However, the events 
described in this section are not user interface events. Rather, an event is a named action or set of actions that may 
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. . Tu. mav be triERcred cither at a specified time or may be activated 

\^ r^o;«CTcd wiih the applicatioo server. The event may oe tnggcrcu r 

•,rL„„is a. *e end of U.C business day. or sending alen n^ssages. Fox cxanrplc, one use of an event 
:I.o . con^,. w.en .vcoxy .evels dxop . ^-in .ev^ ^ 

:;"irLp.cfe««yin,,e„«.«^.ven,se,viccU..ea.^^^^^^ 

'^'"t:"..3veana^.poss...a.i^^ 

a„HbuJ^levents>^*n...iplcac.ons.anexecnUono«iexf«U.cac.o« ^"""tl 
rrZ^to execute ei^concnnenUyorsoiany. Possible action, include t»a^ « application softwa„ 
• Ik such as a Java« Servlet. sending «. email, etc. Adminis^ton, can configure even« to occur 

^^r^entbynan.i^code.sucbasa.av,-Sc.lct.E)B.etc..o,aaC-con^n^ 

S^.TZZc^ consents n.y be handled by sepaxau Processes engine. ^ an ev««.. tun« goe. 
above. Java and CVC mpo . . Events may be triggered either synchronously « . 

15 off or h is caUed from code. Ac associated actions occur. Evews y w 
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calledasaresunoi tiiBBcr«e « «siik of triMoing an event may tos 

an event is represented by a separate ValLisL The event Afl may p 

.methods to add/dcUte/enumeiate actions. ^tearfustet to one embodimem of the 

AS described above, multiple appUcation servers n»y be grouped m a duster, to '^^''^^ 
ventset^ce events. oraparticulareven..rnaybeconf.g-red.obaveach«ter.widesc^ 

nr^:; JdMgisI- for .very server in the duster ^ needs then. Bach event may have 
:JL!1 specif whid. application server the event shouM run on. load bdanc^ Events «. 

e Events may be registered on muWpleappBcation serves, to one emhodm«nt. event 
application server engme. Events may be reg« ^ ^ ^ 

1. o. r*eistration. adding actions, getnng . attributes, etc. may occu. «. f 
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Event API 

This section discusses one embodiment of an API for managing and using events. 

To create a new event, use the following pioceduic: 
5 1. Obtain the event manager object by caJling gctAppEvent( ). For example: 

IA|ip£vent cventMgr » getAppEventO; 

2. Specify ihe characteristics of the new event by setting up an IValList object with a set of values, each one being 
one characteristic of ihc event. The vahies required in this object vary depending on whether the event's action is to 

10 run an application conqwnent, send an cmafly etc 

3. Infoiin the application server of flic new event by calling register£vait( ). 
For example, the following code sets up an evem to send email: 

15 

IValList eventOutput; 
IValList cventlnpua «= GXCreateValUstO; 
Stxing evciitHame2 "ReportEvent"; 
// Add the ReportAgent appevent name to ^ vallist 
20 evcntlnput2jetValString(GX.AEJlEJCEYJNAMEXjX_AEJ^^ 
eventName2); 

// Set the appcvcnt state to be enabled 

evcntInput2.setValInt(GX.AE_RE_KEY_STATE.t3X.AE.l^_I^ 
GX_AE_RE_ES_FLAG.GX.AE.RE.EVENTJENABLED); 
25 //Set the appevent time to be 06:00:00 his everyday 

eventInput2^tValString(GX_AE_RE_KEY_TIME:GX.AE_RE_K^ 

-6K)K) •/•/•"): 

// Set the appevent action to send e-mail to 
// report@acnic.com 

30 eveniInput2.sciValSiring(GX_AE.RE_KEY_KnOXa_AE_l^_KEY_N^ 
"rcport@acme.com'); 

// The content of the e-mail is in /mqii^epoit-file 
eventIzqmt2.setVa]String( 

GX_AE_RE^KEY.MFlLE.GX_AE_RE_iaEY_MFILE, 
35 "/tmp/report-file"); 

// The e-maO host running the SMTP server is mailsvr 
eventInput2.setValString( 

GX_AE_RE.KEY_MH0ST.GX_AE_.RE_KEY_MHOST. 
••mailsvr.acmc-com"); 
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// The sender's e-mail address is adxniD@acme.com 
cventIiiput2^tValString( 

GX_AE_RE_KEY.SADDR.GX_AE_RE_KEY_SADDR. 

*adiDin@acme.c(mi'0; 
//Register the event 

if (cvcntMgrjegistcrEvent(cventNamc2, eventlnput2) 
f^GXE^CCESiS) 

return streamResult("Can not register ReportEvent<ta>"); 



Triggering an cxistiiig ievent: 

TypicaUy. an event is triggered at time intervals which you specify when you create the event. You can 
also trigger the event at any time from code. The event stifl occurs at its timed intervals also. Tliosc events that do 
not have a timer are triggered only when called from code. 



15 



To trigger an event: 

L Obtain die event manager object by calling getAppEveotO. Forexan^ile: 
lAppEvent eventMgr - getAppEventQ; 

20 2. If you want to change any of the characteristics of the evert before running it^ 

desired characteristics. Use the same techniques as you did when setting up the event, but include only diose 
characteristics ycm wart to ovenide. For example: 
IVaBList ncwPiops » GX-CreateVaHistO; 

ncwProps.sctValString(GXJ^JlE_KEYJIREQ.GX_AEJlEJC^ 
25 -RunReportV2"): 

3. To trigger the event, call sctEvent(). For eMmpk: 
eventMgr.setEvent("ReportEvent'',0.newPnjps); 

30 

Deleting an event: 

Delete an event when the evert and its actioiis are not incaningM anymore, or if you wa^ 
only during the lifetime of an qiplication conq»onert execution. 

35 To delete an evert: 

1. Obtain the event manager object by calling getAppEvent(). For exairqjle: 

lAppEvent eveniMgr « getAppEvenlQ; 

2. To delete the event permanently, call deleteEvcnt( ). For example: 

34 
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Temporarily disabling an event 

Disable an event if you don:t want it to be triggered during a temporary period. For example, you migjit 

not want to generate reports during a company holiday. 
To disable and enable an event: 

1. ObtainthecventmanagcrobjcctbycallinggetAppEventO. Forexamplc: 
lAppEvent evcntMgr « gctAppEvemO; 

2. To stop the event torn naming temporarily. caUdisableEventC). For exaii^ 
evcntMgr.disableEvent("ReportEvenl"); 

3 When you want the event to be available again, caU enablcEvent( ). For cxampk: 
evcntMgr.enablcEvent("ReponEvcnr); 



Getting infomiatiosi about events 

To get infonmtion about a panicular event. caU que,yEve»t( ). TTus method ten»>s .be IVaHJst olgeet 
Uuit co».aii« the chan-cterisdcs of .he event. To get con.pleu dcufls abcmt .U the cuneady defined ev««. fim 
«B en«n,Evea«( ). Tim ineU«»d «nHm fl« IValljst objee« of an the events ta^ 

can en««Nex< ) to step duoogb the IVaHJst objeos «tun«l by e««n.Even.s( ). The e«un£ve«s( ) »>d 
<p«yEvent( )methods «^ defined in d>e lAppEvent interface. IT- en«riNe«K ) method i. defined m the 

lEnumObject interface. 
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Exan^le: 

The following code generates a report of all registered events. 

// Open /tmp/repoTt-filc for writing the report 

FileOutputStreain outFile ° null; 
5 outFile = new FileOutputStreamC/tmp/report-fllc"); 

ObjectOutputStrcaro p «= null; 

p = new ObjectOutputStreain(outFilc); 

// get appevent manager 

lAppEvcnt appEvcnt = gctAppEventQ; 
10 // Get the Enumeration object containing ValLists for all 

// the registered events 

lEnumObject enimiObj * appEveni.enuniEventsO; 
// Retrieve the count of registered appevents 
int count *^ exnunObj.emmiCountOs 
15 p.writcObjcctCVumber of Registered Events: 
p.writelnt(count); 
enoxnOt3j.enumReset(0); 
while (cotuil>0) { 

lObject vListObj ^ enumObj.cnuraNextO; 
20 IVallist vList « (IValList)vListOI:g; 
String name 

vlJsLgctValString(GX.AE_RE_KEYJ4AME.GX_AEJUEJC^ 
p.writeObjcct("\nDclinitions for AppEvent named "fc 
p.writeObject(name); 
25 p.wiiteObject(nn"); 

// Reset the next item to retrieve from ValList to be 
// the Hist one 

vLisLresctPositionO;// Iterate through all the items in the vallist and 
//print them 

30 while ((name - vUsLgetNextKeyO) i*^ ( 
GXVALval; 

val » vList-getValByRcHname); 
p.wriicObject("\n\t"); 
p.writeObject(name); 
35 p.wTitcObjcct(" ■= "); 

p.writeObject(vaLtoStriQgO); 

) 
} 

36 

BNSOOaD- «WO ^01 13227A2J.> 



wo 01/132Z7 



PCTAJSOO/22055 



Example tnterface for event API: 

interface IGXAppEvcntMgr { 
HRESULT Create£veiit( 
5 [in] LPSTR pEventName. 

lout] IGXAppEventObj ••appcventObj 

); 

HRESULT RcgisierEvcnt( 

|in] IGXAppEventObj* appEventObj 

10 ); 

HRESULT Get£veiit( 

[in] LPSTR pEvcntNamc» 

[out] IGXAppEventObj ••pAppEvenl 

15 ); 

HRESULT TriggerE veot( 
[in] LPSTR pEventName, 
[in] IGXValList •pInValList, 
20 [in]BOOLsyncFbg 

); 

HRESULT £Dable£veot( 
[in] LPSTR pEventKan^ 

25 ); 

HRJESULT DisableEvcid( 
[in] LPSIR pEventName 

y; 

30 

HRESULT DeleteEvcntC 
[in] LPSTR pEventf^ame 

); 

35 HRESULT EnumEvents( 

[out] IGXEnumObject **ppEvents 

); 

) 

40 Descriptions: 



CieateEvent 

pEventName: name of the event to be registered, 
appcventObj: pointer to returned appcvcnt objett. 
45 CreateEvent creates a empty appcvcnt object Amibutes and Actions can be set on the returned appevenfOl^ and 
then registered with AppEventMgr using RegisterEvent Note that changes to appeventObj do not take effect untfl il 
is registered with die Manager^ 



RegisterEvent 

50 appeventObj: pointer to appevent object that is to be registered. 
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Rcgisieis a appevent object whose anributes and actions have been setup. AU changes to appEvcntObj are 
conrniincd to the server, and the registiy. If an appevent object already exUts for the given name, then that object is 
deleted and this new object will take its place. 

5 GetEvent 

pEventNanie: naine of the event 

appcvcntObj: pointer to ictunicd appevent object 

GetEvent retrieves a appevent object for a given event name. 

10 TriggcrEvent 

pEventName: name of the event to be triggered. 

pValLisu input ValList that is passed to Actions. 

syncFlag: boolean flag to denote if event is to be triggered synchronously. 

Triggers a specified appevent A copy of plnValList is passed as input to aU actions registered with the appevent 



15 



20 



25 



30 



If the Action is an applogic, then plnValUst is passed as mpat to that applogic 
If the action is a inail. then plnVaHJst is currently siraply ignoied. 

If the action is a Scrvlet. then the enuies of the input vallist are available as atuibutes of SeivletRequest object Hat 
is passed to the Servlet 

If syncFlag is FALSE, then the event is triggered, and the caU immediately returns widioiit waiting for Ae 
to complete execution. If the flag is TRUE, then this call blocks until the event is triggered and aD actions 
executed. 

Actions are triggered exactly in the order they have been added to the appevent object 



EnableEvent 

pEventNamc: name of the event 
Enables a appevent 

DisableEvcnt 

pEventName: name of the event 
Disables a appevent 



35 DeleteEvent 

pEventNante: name of the event 

Delete a appevent from the system and the regisuy. 

EnuroEvents 
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ppEvcnts: pointer to retuined enum object 

Enumerates all appevents that are registered with the server. Each clement of the returned Enrnn object contains a 
appeveni object (of type IGXAppEventObj). 

5 interface IGXAppEventObj { 

. HR£SULTGetNan]c( 

[out, size_is(nName)] LPSTR pName, 
[in, defai4t_vahte(256)] ULONG nName 

10 ); * 

HRESULT SctAttributes( 
[in] IGXValList* attrlist 

15 HRESULT GetAttribQtes( 

[out] IGXValUst** attrUst 

); 

HRESULT AddAction( 
20 [in] IGXValLast* action 

y. 

HRESULT I>cleteActions( 

25 

HRESULT EnuniActians( 

[out] IGXEnumObject*^ actioat 

); 

30 ); 

GctName 

pName: pointer to a input buffer. 
nName: size of input buffer. 
35 Gets the name of the appevent. The name is set when the object is created with CfeateEventQ- 

SetAttributes. 

atirList: input attribute vailisL 

Sets the attribute ValList of the appevent. Note that changes to an appevent object are not twmmitted until it is 
40 registered widi the AppEvenlMgr. • 

GctAttributcs 

attrList: pointer to returned attribute vallisL 
Gets the attribute vallist of a appevent. 



45 



AddActioD 

action: input action vallisL 
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AddAction appends an action to a ordered list of actions. When an event is triggered, the actions arc executed 
exactly in the order they have been added. ValList entries describe the action being added, and vary from one type 
to another. 

5 DeleteActkxDS 

Delete all actions added to this appevent object 

actions: pointer to returned enum object 
10 Enianerates actions added to. this appevent object Each entry in the returned enum object is a action vallist of type 
IGXValList 

Sample pwtion of registiy: 

6 EVENTS2 0 

15 7 tstEvl 0 

0 Enable 4 1 

0 AcdonMode 4 1 

0 Time 1 •.•0.10^030,40^0.-0 •/•/• 

0 ActionCouat 4 4 

20 S 1 0 

0 Sequence 4 1 

0 NewReq 1 GUIDGX-{754CE8F7-8B7A-153FO8B-p800207B8777) 

8 2 0 

0 Secpxence 4 2 

25 O ServletReq 1 HenoWorldServlet?aigl^ll&aigii2-'valii2 

8 3 0 

0 Sequcaee 4 3 

0 MailFile 1 /u/kchinta/appevjnafl 

0 SesderAddr 1 ichima 

30 0 MailHost 1 iisniail>2 

0 ToList 1 rchinta 

8 4 0 

0 Sequence 4 4 

0 NewReq 1 GUIDGX.{754CE8F7-8B7A-153F-C38B-0800207B8777) 

35 7 tstEv2 0 

0 Enable 4 1 

0 Tnne 1 •:8:0*/*/* 

0 ActionCount 4 1 

8 10 

40 0 Sequence 4 1 

0 NewReq 1 GUnXjX-{754CE8r7.8B7A-153F-08B-0800207B8777)?|il-=helloO 



Request Stem 

45 In various enibodiinents, an application server may handle req[uests using a workflow model of defining a 

series of steps for each type of request As a simple example, consider the application server architecture shown in 
Figure 3, in which a request of foin- steps is processed. The first step may be to determine the appropriate entity to 
handle the request For example, the executive server 202 may broker a request to the Java server 204 if the request 
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references a Java™ coxnponcnu or lo ihc OC++ server 206 if ihe request references a C++ component, etc At 
another level, the Java server 204 may determine which Java''*' component should handle a request. Thus, request 
Steps may have different meanings in different contexts. 

Continuing the example, the second step may be to load the entity found in step 1 above. For exanq>le, the 
5 Java server 204 engine may instantiate the appropriate Java^ objecL Some steps may not apply in certain conteJds. 
For cxan^Ie, step 2 may not apply to an executive server-level request, since the appropriate server pr process to 
hand off a request to is probably already ninning. 

The third step may be to "Vun" the entity using the request context, e.g. request parameters. For exanqile, 
this run step for the executive server may mean to send the request data to the Java server and await the results. Fdr 
10 the Java server, this run step may mean to run the. Java^ con^nent on the Java"*^ virtual machine. 

The fourth step may be to stream back the results generated in the third step to the originating requestor. 

Different step lists may be defined for each type of request. For example, the step list for a request 
referencing an Enterprise JavaBean'^ may be different from the step liist for a request leferendng a Java^ Scrrkt. 

This method of representing requests as a series of steps provides advantages such as the flexibility of 
15 weaving steps in any way desire.d for a given level; Also, steps may be easily added into the step list. For ^^^J^,. 
while traditional programming models may require code to be recompiled or reloaded in order to alter veqiiest 
logic, the step model allows a new step to singply be added. 

Request Qucueing 

20 Each request received fiom clients such as web servers may be packaged in a data packet having a* 

parttcttlar format. Accordix^ to this format, a field in the data packet may specify a sub-protocoL This sub- 
protocol may specify whidt step list to use for the request. 

A request manager service and queue and thread managers are discussed above with reference to^iguie 4. 
If a request needs to be queued, for exanq>le if all the request*handling threads are busy processing requests, then 

25 the request may be placed into different queues based on the type of request A thread pool may be associated widi 
each request queue. Threads in different thread pools may have different characteristics. Tor example, requests 
requiring XA behavior, as defined by the XA standard protocol, may be placed in a request queue that has an 
associated thread pool comprising XA-cnabled threads. If at some point while a request is being processed it is 
determined that the request needs to be handled by a diiTcrent thread, then the request may be re-queued in the 

30 appropriate queue. For example, if a non^XA-enabled thread is processing a request, and the application logic 
detennines that the request now requires XA behavior, then the request may be requeued into a request queue wth 
an associated thread pool comprising XA-enabled threads. Optimizations are preferably p eif o i mcd so that Ae 
. request does not have to repeat the entire overhead of being taken from the networic stack, unmarshaled, dc 

35 LogEing Facility 

In various embodiments, the application server may provide a robust, flexible logging facility, as described 
in this section. When logging is enabled, messages generated by application-level and system-level services may 
be logged. These messages describe the events that occur while a service or application is running. For exanq>le. 
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each time Ae server connnunicaies wiA a database, the logging facflity may record the resuhmg messages 
generated by a database access service. 

Determining Types of Mes sages to Log 

Various types of messages may be logged.' In one embodiment, messages are categorized into the foHowing types: 

. Information message. Describes the processing of a request or normal service activity, suchas a status updMe. 

• Warning message. DcscnT)es a non-critical problem diat might be an indiditioii »• laiger pr**leaL For 
example, when a service is unable to connect to a process, a warning message may be logged. 

• Error message. Describes a critical faihire of a service, from which recovery is not likely. For example, when 
a service encounters a critical problem, sud> as a pipe closure. 

A user interface may be provided to manage message logging. e.g..enabling/disabling logging, specifying 
die types of messages to log. etc. An example of a user interface to manage message logging is shown in Figure 20. 
In Figure 20. die Maximum Entries field specifies die maximum number of entries durt can exist before dat> is 
written to die log. -nu: Write Interval field specifies die amount of time (in seconds) that elapses before dat* is 
written to d« log. me Message Type field specifies wMcb types of messages should be logged finfmmational 
messages, warnixi^ and/or enois.) 

Log Message Fonnat 

In one embodiment, log messages has the following four cox^nments: 

• date and time the message was czeated 

• message type, swdi as mfomlatioI^ waniing, or enar 

• service or application component ID generating message 
•message text 

Logging Destination 

•me logging service can preferably be configured to record server and application messages in any or aU ofihe 
foUowing destinations: 

• Process consoles. By default, die process consoles may display log messages as diey are geiierated. If logging 
is enabled and die server is enabled for automatic startup (UmC) or interaction widi die desktop (NT), the 
consoles open and display die log messages. This feawre can be disbaled by deselecting die Log to Console 
checkbox. 

. Application log. The defauh application log file. For Windows NT. diis may be viewable dirougb die Event 
Viewer. This is die default Provides a more comprehensive record of die server and appBcatioii crmr 
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20 



messages. Warning and infonnaiion messages arc not logged to the application log. AU messages are sorted by 
their amestamp. 

• ASCn text flic. An ASQI text file, which the user can create and specify. Used for a more permanent record 
5 of the server and application messages. All messages are soiled by their timestanop. 

• Database uble. A database table which can be created and specified. This may be the most versatile logging 
destination and can be used when it is desired to sort, group, and create repbrts of the logged messages. 

10 In one embodiment, the server may use a log buffer to store messages before they arc written to the 

application log, an ASOl file, and/or database logs. This buffer optimizes the performance of the application server 
by limiting the use of resources to continually update a log. The buffer is written to the destination when eiAer the 
buffer interval times out or the number of entries in the buffer exceeds the maximum number allowed. 

1 5 TTie following messages sent to an ASCII text file illustrate exenq>lary formats of text 
[1 1/18/97 1 1:11:12:0] info (1): GMS-017: server shutdown (host 
QxcOaSOlae, port 108 18. gn)up •MIS') - updated host database 



[11/18/97 11:11:18:2] warning (1):GMS-019: duplicate server (host 

0xc0a80l7f, port 10818) recognized, please contact sales representative for additional liceiises 



Logging to a Database 

If messages are to be logged to a database, an event log database table may be created. -Figure 21 iUnstrates an 
exemplary type of database table for logging messages. On some systems, supplied scripts may be used for 
25 automaticaUy setting up database tables. The application server logging service may map the message elements to 
the database fields listed in the table. 

FDe Rotation 

As shoWn in Figure 20, the application server logging faciUty may be configured to rotate ASOI logtites 
30 at scheduled time intervals. When a log file is rotated, the existing log file may be closed and moved to an archive 
location, and a new log file may be created for recording further log events. Since log liks are stamped wifli tfie 
time and date dicy are created, log file rotation helps organize log files into manageable units. The times at ^Meh 
the log files should be rotated may be specified using a reguhir time interval, as ilhistrated in Figure 20. or using a 
string expression, e.g.. by typing a string into the field shown. In one embodiment, a ^ring expression should be of 
35 the format: 

|il>*Tnm*g< W/DD/MM 

where the following table explains each element of the expression: 
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Element Explanation Possible Values 



bh houroftheday 0*23 

mm minute 0-59 

5 ss seconds 0*59 

W day of tfie week 0 • 6 (0 for Sunday) 

DD day of the mondi 1*31 

MM month 1-12 

10 Each of these fields may be cither an asterisk or a list of elements separated by commas. An element is 



either a number or two numbers separated by a minus sign, indicating an inclusive range. An asterisk specifics aO 
lejgal values for that field. For example, the expressicm: 
2, 5 - 7:0:0 5/*/* 

specifies that logging should be rotated at 2:00am, 5:00an\ 6:00aro and 7:00am every Friday. The specification of 
15 days can be made by two fields: day of the month (DD) and day of the week (W). If both are specified, then hoih 
may take effect For example, the expresstoo: 
l.Hk01/15r 

specifies that loggiz^ to a new file starts at 1:00am every Monday, as well as cm die fifteenth of each month. To 
specify days by cmly one field, the other field may be set to **^. 

20 

In one embodiment, the following environment entries, which may be in^Iemented as registry entries, are provided 
to manage log file rotation. A user interface such as shown in Figuze 20 may be provided to set these entries. 

• EnableRotationzLogfilerotationwillbeenabledwhensetto'*!**, or disabled when set to By default, log 
' fUe rotation is disabled. 

25 • Rotatellme: An expression string denoting the time at which die log file is to be rotated. 

• TextPatfa: In one cnibodiment, when log file rotation is not enabled, the name of each log file is based on die 
value of the TextPath entry, plus the process ID of the logging process. When log file rotation is enabled, die 
name of each log fDe is based on the value of the TextPath entry, plus the process ID, phis the time at which 
the file is created. A file name may be of the format <TextPath>_<process-id>_<time*created>, "wbac 

30 <TextPadi> is the value of the TextPath entry, <process-i(> is the id of the logging process, and <tiiDe- 

created> is the time at which logging to the file started. 

Loggii^g Web Server Requests 

The application server may be configured to log web server requests. For example, a web server plug-in 
35 such as shown in Figure 4 may send requests to the application server where they are processed. By logging web 
server requests, request panems and other iii^onant request infoimation may be tracked. 

Web server requests may include HTTP requests. A web server HTTP request may be divided into 
standardized HTTP variables used by the web server to manage requests. The application server may include dicse 
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or a subset of these HTTP variables to be logged. Variables may be added to the list if additional log infonnation is 
desired. In one embodiment, each HTTP variable is mapped to a field name in a database table. Figure 22 
illustrates an exemplary type of database table for logging web server requests. On some systems, supplied scripts 
may be used for automatically setting up such a table. 
5 Note that Fxgtire 22 illustrates a Held nanse of **logtime*' in the database table. The application server 

logging service may record the time that the message is created in the logtime database field. Note that datab^^ 
field name may be renamed. The fields from the database table may be automatically mapped to web server 
variables in the registry.' 

10 Out of Storaec Space Condition 

One problem that is not handled well, or not handled at all, by many application server logging facilities is 
an out-of-storage-space condition, such as an out-of-disk-space condition. Since many other logging facilities do 
not handle an out-of>storage*qpace condition gracefully, this condition causes many other application servers to fail, 
e.g. by crashing. 

15 Thus, when running out of storage space, the application server may automatically suspend logging tmtfl 

more storage space becomes available. Logging may then resume when storage space becomes available. In one 
embodiment, it is guaranteed that when the application server suspends logging for lack of storage space, a message 
to that effect wiD be written to die log file. The applicatioai server logging facility may reserve a certain amount of 
disk space to write such a message if necessary. The logging facility may suspiend logging for tixe duration of tibe 

20 out-of-storage space condition, and then automatically resume logging when the condition is corrected. Hie 
application server logging facility may monitor the amoimt of available storage space, e.g. via a task that wakes up 
periodically and performs this check. 

Figure 23 is a flowchart diagram illustrating one embodiment of a method for handling out-of-$torage> 
space conditions. As shown, in step 500, an amount of storage space may be reserved, e.g., at the stannp time of 

25 the logging service. This storage space may be disk space or another type of media storage space, depending m 
where messages are logged. The amotmt of storage space reserved may vary, but is preferably a relatively smaO 
amount suitable for logging as out-of-storage space condition message, as described below. The storage space may 
be reserved in any of various ways, depending on the particular operating system, programming language, et& 

As shown in steps 502 and 504, the amount of storage space currently available may be chedced 

30 periodically. For example, the logging service may create a thread that wakes up periodically and performs this 
chec^ 

if an out-of-storage-space condition is detected, then message logging may be suspended, as shows in step 
506. In one embodiment, the logging service may simply ignore requests by client processes to log messages while 
message logging is suq>ended. The logging service may return an error code to ^ client indicating that the 
35 message was iK>t logged. 

In step 508, a message indicating the out-of-storage-space condition may be logged, using the storage 
space reserved in step 500. In various embodiments, other actions may abo be taken in response to an oistH»f- 
storage space condition. For exan^le, an administrator may be alerted via an email, a page, etc. 
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As shown in step 510, the logging service may periodically check fot available storage space and may 
resume message logging if storage space becomes available. For example* a thread may periodically wake iq> to 
perform this check. Upon resuming message logging, the logging service may of course reserve storage space for 
logging an out-of-storage-space condition again if necessary. 
5 As noted above. Figure 23 represents one embodiment of a method for handling out-of-storagc-space 

conditions, and various steps may be added, combined, altered, etc. For example, the logging service may be 
operable to check for declining storage space and may aleit an administrator, e.g^ via an email, before such a low 
level of storage space is reached that message logging suspension becomes necessary. As another example, in one 
embodiment, the logging service may queue logging requests received from client processes in memory while 
10 message logging is suspended and may attempt to log fhe messages once storage space becomes avaOable. 

Although the embodiments above have been described in considerable detail, numerous variations and 
modiflcations will become apparent to those skilled in the art once the above disclosure is ftiUy appreciated. II is 
intended that the following claims be interpreted to embrace aQ such variations and modifications. 
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WHAT IS CLAIMED IS: 

L A method for enabling applicadon server request failover, the method comprising: 
a requesting thread running in a client computer sending a request to an applicadon server, wherein the 
5 application server is operable to receive the request, process the request, and return request results to the requesting 
thread; 

the requesting thread sleeping after said sending the request to the applicadon server; 
the requesting thread waking up and sending a poll message to the application server, wherein the poll 
message comprises infonnadon identifying the request, wherein the application server is operable to receive die 
10 poll message and respond by returning a status of the request to the requesting thread. 

2. Themethodofdaim 1, further comprising: 

the requesting thread determining whether a response to the poll message is received from the applicatioo 

server. 

15 

3. The method of claim 2, further conqyrising: 

the requesting thread receiving a response to the poll message from the application servcx; 
the requesting thread analyzing the response to determine whether the application server is cunienlly 
prooesssittg the request 

20 

4. The method of claim 3, frtrdier conqnising: 

the requesting thread returning to sleep if the appticadon server is ctnrently processsii^ 

5. The method of claim 3, furtidcrconqirising: 

25 the requesting thread re-sending the request to the applicadon server if the applicadon server is not 

currently proccsssing the request 



6. The method of claim 2, wherein information regarding the current state of the applicadon i 
is maintained on the client computer, the method iuithcr co jnpr i sin g: 
30 the requesting thread determining that a response to the poll message is not received from the application. 



the requesting thread causing the client computer to update the infonnadon regarding die current state of 
the application server to reflect that the application server did not respond to the poU message. 

35 7. The method of claim 6, wherein the application server is a first applicadon server in an 

appHcation server cluster conqmsing the first applicadon server and a second applicadon server, the met h od furtfier 
conqsrising: 

the requesting thread sending the request to the second applicadon i 
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8. The method of claim 6, further con^rising: 
the client compulei periodical^ polling the application server, 

if the application server responds to said polling, the cHent computer updating the infonnation regarding 
the current state of the application server to reflect that the application server responded to said polling. 

9. The method of claim 6» 

wherein said updating the infonnation regarding the current state of the application server to reflect that 
the application server did not respond to the poU message results in the client computer not sending future requests 
to the appHcation server. 

10. The method of claim 6, 

wherein said requesting thread determining that a response to the poll message is not received from the 
appHcation server is accompHshcd by the requesting thread determining that a response to the poU message is not 
received from the application server witiiin a certain period of time. 

11. The method of claim 1, 

wherein said sending a poll message to the application server comprises sending a User Datagram Protocol 
(UDP) message to f£bc application server. 

20 12. The mcdiod of claim 1, 

wfaeidn said requesting thread waking up and sending a poD message to die appHcation server ts 

performed periodically. 
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13. Hie method of claim 1, 

wherein said requesting thread waking up and sending a poll message to the application server is 
perfomied periodically at time intervals specified by an administrator via a user interftcc 

14. The mediod of claim 1, 

wherein the request references a component running on the appUcation server. 

15. The method of claim 14, 

wherein the component is a con^ncnt from the group consisting of: 

a JavaServcr Page con^ncnt. a Java Scrvlet component, an Entaprise JavaBeans componem. 

35 16. The method of claim 1, 

wherein the client corxqmter is a web seiver couiputer. 

17. A system comprising: 

a client con^uter including a CPU and meroody; 
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a requesting thread stored in the memory of the client computer, wherein the requesting thread is cxperable 
to send a request to an application server coir^uter; 

an application server computer including a CPU and memory, wherein the applicadon server is operable to 
receive the request, process die request, and return request results to the requesting fHTTftd: 

a network connecting the client computer to the application server computer; 

wherein the requesting thread is executable to sleep after said sending the request to the application server; 

wherein the requesting thread is executable to wake up arid send a poU message to the application server. 
iK^ercin the poU message con^rises information identifying the request, wherein the application server is operable 
to receive the poll message and respond by returning a status of the request to the requesting thread. 

18. The system of claim 17, 

wherein the requesting thread is further execuuble to determine whether a response to die poll mrysage is 
received from the aj^lication server. 

19. Thes^temofclaim 18, 

wherein the requesting thread is further executable to receive a response to. die poll message from die 
apphcation server; 

wherein the requesting thread is further executable to analyze the response to determine whether the 
plication server is currently processsiBg the requeft 

20. The system of claim 19, 

wherein the requesting thread is further executable to return to sle^ if the apptication server is cuncady 
processsing die request 

21. The system of claim 19, 

i^ercin the requesting thread is further executable to re-send die request to the application server if die 
apphcation server is not currently processsing the request 

22. The system of claim 18, 

wherein the client con^uter is operable to maintain information regarding die current state of the 
application server conoputer; 

wherein the requesting diread is further executable to determine that a response to the poll message is not 
received from the application server; 

wherein the requesting thread is further executable to cause the client counter to tipdate the infonnatioa 
regarding the current state of the application server to reflect that the application server did not respond to the poU 
message. 
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23. The system of claim 22, wherein the application server computer is a first application server 
coxnputcr in an application server cluster comprising the first application server computer and a second application 
server computer, 

wherein the requesting thread is further executable to send the request to the second application server 

5 CtUUpUlBT. 

24. The system of claim 22, 

wherein the client comsniter is operable to periodically poll the application server co mpu t e t ; 
wherein, in response to receiving a response to the poUing message from the application server computer, 
10 the client con^uter is operable to update the infoimation regarding the cuirent state of the application server to 
reflect that the application server responded to said polling. 

25. Ihe system of claim 22, 

whetein said' updating the informatian regarding dbe current state of the application server to reflect that 
15 the application server did not respond to the poU message results in the client con^puter not sending future requests 
to die application i 



26. The system of claim 22, 

whcnin said requesting thread determining diat a response to the poU message is not received fimn the 
20 applicatifm server is accoaq>lislMd by the requesting dsead deteimining diat a response to die poO message is not 
received from the application server within a certain period of tisK. 

27. The system of claim 17, 

wherein said sending a poO message to the application server coiz^rises sending a User Datagram Protocol 
25 (UDP) message to die application server. 

28. The system of claim 17, 

whexein said requesting thread waking up and sending a poO message to die application server is 
pcxfoxmed periodically. 

30 

29. The system of claim 17, 

wherein said requesting thread waking tip and sending a poD message to the application 
performed periodically at time intervals specified by an administrator via a user inter&oe. 

35 30. The system of daim 17, further c oni]niMH g ; 

an application component running on the application server computer; 
' wherein the request references die application con^xmeaL 
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31. The system of claim 30, 

wherein the component is a conxponent from the group consisting of: 

a JavaScTvcr Page con^nent, a Java Servlet component, an Entexprise JavaBeans compoDenL 

5 3Z The system of claim 30, 

wherein the client compoter is a web server conqniter. 

33. A memory medium con^rising program instructions operable to iinplemeai: 

a requesting thread rutming in a client computer sendiiig a request to an application server, wherein die 
10 application server is operable to receive the request, process the request, and return request results to die xequestiiig 
docad; 

die requesting thread sleeping after said sending the request to the application s erve r , 
the requesting thread waking vp and sending a poll message to the application server, wherein the poll 
message coxzqirises infoxmadon identifying die request, wherem the appltcadon server is i^>erable to receive die 
15 poO message and resprod by retuxniDg a status ofdie request to die reqpiestiiigdi^^ 

34. The memory medium of claim 33, further comprising program insii u ctiuns operable to 
nriplftnient? 

die requesting duead determining whether a response to the poll message is received from die application 

20 



35. Ihe memory medium of claim 34, furdier comprising program instructiaiis operable to 
rmplcmeDti 

the requestmg thread receiving a response to the poll message from the application server; 
25 the requesting thread analyzing the response to determine whether the application server is c u nei itly 

processsing the request. 

36. The memory medium of claim 35, further conqirising program instructions operable to 
flDDplemeot. 

30 die requesting thread returning to sleep if die application server is cunendy processsing die request. 

37. The memory medium of claim 35, further comprising program instructions operable to 
' uxiplcmentr 

the requesting thread re-sending die request to die application server if the application server is mit 
35 ■ currently processsing die request 

38. The memory medium of claim 34, wherein the client computer is operable to Tniwaa^ 
information regarding the current state of die application server computer, the memory medium furdier comprising 
program instructions operable to inclement: 
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the requesting thread deteiminiDg that a response to the poll message is not received from the appli c a t ion 



the requesting thread causing the client coxnputer to update the information regarding the cuircnt state of 
the application server to reflect that the application server did not respond to the poll message. 

39. The mcmoiy medium of claim 38. wherein the application server is a first application server in an 
application server cluster comprising Ae first appUcation server and a second application server, die memoxy 
TT»<»rfimn further comprising program instructions operable to implement: 

the requesting thread sending the request to die second application server. 



40. The memory medium of claim 38. further comprising program instructions operable to 
mylcrncntr 

the client computer periodicaUy polling the application server; 

if the application server responds to said polling, the client computer updating the information regarding 
15 the current state of the application server to reHect diat the ai^lication server responded to said polling. 

41. The memoiy medimn of claim 38» 

wheiein said updating the infbrmadon regarding die current state <^ the application server to reflect dot 
the application server did not respond to the poU message results in the client computer not s endin g future requests 
20 to die application server. 

42. The memoiy mediimi of claim 38» 

wlieiein said requesting thread detetminxng that a r esp o n s e to die poU m es sage is not received from die 
appbcation server is accomplished by the requesting thread determining that a response to die poll message is not 
25 rccdvedfromtheappbcationserver within a certain period of dine. 

43 . The memoiy medium of claim 33, 

wherein said sending a poll message to the application server coixq>rises sending a User Datagram Protocol 
(UDP) message to die application server. 

30 

44. The memoiy mediima of claim 33» 

wherein said requesting thread waking t^ and sending a poll message to the applicatioii scsver is 
performed periodically. 

35 45. The memoiy medium of claim 33, 

wherein said requesting thread waking up and sending a poQ message to the application server is 
performed periodically at time intervab specified by an administrator via a user intci&ce. 
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46. The memory medium of claim 33, 

wherein the request references a component running on the application server. 

47. Thememory medium of claim 46» 

wherein the conqponent is a cdxnponeDi. from the g^oxxp consisting of: 

a JavaSeryer Page component, a Java Servlet cozxiponent, an Enterprise JavaBcans co mponen t 

48. Thememory medium of claim 33» 
iK^erein the client conq>nter is a w^ server computer. 
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